← The Agile Brand with Greg Kihlström®: Expert Mode Marketing Technology, AI, & CX
The Agile Brand with Greg Kihlström®: Expert Mode Marketing Technology, AI, & CX
#740: Navigating Build vs. Buy with Luv Kapur, Bit
00:30:23
Loading summary
Transcript36 lines
- [00:01]
A
The Agile Brand.
- [00:10]
B
Welcome to Season seven of the Agile Brand where we discuss the trends and topics marketing leaders need to know. Stay curious, stay agile and join the top enterprise brands and martech platforms as we explore marketing technology, AI, E commerce, and whatever's next for the omnichannel customer experience. Together we'll discover what it takes to create an agile brand built for today and tomorrow and built for customers, employees and continued business growth. I'm your host Greg Kilstrom advising Fortune 1000 brands on MarTech, AI and marketing operations. To make sure you always get the latest episodes, please hit subscribe on the app you listen to podcasts on and leave us a rating so others can find us as well. Now on to the show. This episode is brought to you by bit. In the age of AI, don't just generate code compose software. BIT helps you create and reuse independent components to build reliable scalable applications. Stop rebuilding and start shipping with the AI powered composition platform at www.bit.dev Agility requires a nuanced understanding of not just the technology at hand, but but also the internal capabilities and collaborative potential within an organization. It demands a willingness to adapt strategies, embrace change and prioritize value delivery above rigid adherence to traditional models. Today we're going to talk about navigating the increasingly complex build versus Buy dilemma in the age of AI and how an inner source approach can offer a compelling alternative. To help me discuss this topic, I'd like to welcome Love Kapoor, Staff Engineering Lead at bit. Love, welcome to the show.
- [01:54]
A
Thanks for having me Greg.
- [01:56]
C
Yeah, looking forward to talking about this with you. Definitely a fascinating topic here and one I know I run into quite a bit. But before we dive in, why don't you give a little background on yourself and your role at bit?
- [02:08]
A
Sure, yeah. I'm a staff engineering lead at BIT where my team and I focus on building the core platform that help developers create and share software and components. My background itself is in building large scale systems where reliability was critical as well as speed. Before bit, I spent a number of years leading infrastructure teams for trading applications in finance and how finance is with the classic high stakes environment itself. So we had to ship features incredibly fast. There was zero tolerance for failure and one of the key lessons I learned from my past experience was, you know, the world that we are in, you can't afford to reinvent the wheel, especially when you are shipping fast consistently. And the only way we could move fast and safely was treating our code and as a portfolio of assets. And this is what I learned by working in finance itself, if you treat your code as a portfolio of reusable assets, they're independent, documented components, then you can compose and move very swiftly and create these consistent software for your clients. And that experience is what brought me to Bit. You know, I want to help build the tools that would let any company around the world to achieve the same level of agility. So my role today is now, you know, making that vision of a possible software a reality for everyone.
- [03:27]
C
Yeah, love it, love it. So, yeah, let's talk through a few things here, but I want to start with, I mentioned a term in the intro and I want to get, get your thoughts on a definition here. The inner source advantage. Can you explain what that means, what that approach entails, and how it differs from traditional, maybe open source or purely internal development models?
- [03:52]
A
Absolutely. I think a lot of people are more familiar with the open source model and it's basically applying all the successful principles of open source collaboration, transparency, reuse inside a company's own firewall itself. And, and you can think about how open source works. Your developers from anywhere around the world can discover code, suggest improvements and reuse packages. It's very powerful. A lot of most powerful systems are built upon software that are open source and are driven by the open source principles. And that's what InnerSource entails. It brings all the successful principles of open source to within the company's own environment itself. So instead of teams working in isolated silos, and that's the traditional way where entropy works in a large organization, where teams go get into their own silos itself, they build their own private tools and inner sources pushes them back, it encourages them to publish their work as discoverable, reusable components. So for anyone in the company to use, it's a cultural shift completely, because the traditional way of doing things is this is my team's code, this is what my team is going to deliver, and the shift is to. It's no longer my team's code. This is our company's asset. It breaks down silos, it creates a collaborative ecosystem within the company itself. And of course, for this culture to thrive, you need a central platform where you can host, discover and document and version these components. And that's exactly what Bit itself provides.
- [05:23]
C
Yeah, yeah, that really helps to explain it. And I think the open source analogy is a great one that I think probably a lot of people can understand. I know you touched on some of the benefits, but I wonder if you could talk a little bit more about what some of the key benefits of doing this Are especially when as many companies are faced with that build versus buy dilemma for sure.
- [05:51]
A
And the build versus buy traditional. When companies face this dilemma, they think they have only two binary options. We will either buy software or we will build. Innersource gives you a very powerful third option called composer. So instead of going into two rigid options, build or buy, you get a flexible strategy. And it gives you three advantages. I think the first is you gain the value of having an option itself. You can start by composing a solution from your existing internal components, internal software itself, because this also gives you a good idea what your capabilities are. Before you buy or build, you need to understand what, what your capabilities are, where is the gap and what needs to be fulfilled. And that's where you identify whether that fulfillment of the capability needs to be built in house or needs to be by. And to make a more strategic decision, you need to understand the cost of it itself. So once you have an internal set of inner source components, it gives you visibility on what your capabilities are. It gives you visibility on where the gap is in your own capabilities, why you're looking for a vendor or an option itself. And think about the options to be like, you know, I don't need to pick one or the other. There's a hybrid option where I can identify the gap, compose the solution around it and just either buy that capability itself. The second is also it lowers your vendor lock in. And that's one of the key things with people think when they're going from build versus buy solution that you don't want to be locked into a vendor itself. So if you narrow down the radius of what you are buying from outside the vendor lock in also gets, it gets improved itself. And then third is this goes well with understanding your capabilities because inner source gives you a clear understanding of what you have built, how much it has cost to build and what capabilities are. And gives you true price discovery, the ability to understand if you actually go and buy software, how much it actually costs to build in and how much it is to purchase itself. And you're no longer guessing at that point.
- [07:57]
C
Yeah, yeah. And so yeah, I mean definitely the cost consideration that you mentioned, the time considerations as well, certainly a critical factor. And I do think that as more and more companies that may not have traditionally thought of themselves as software companies, this becomes increasingly important as more software tends to run more and more of companies than again, 20 years ago they might have thought of that. What about the component of AI? Certainly AI is on everybody's minds. While it's not A brand new thing. There's certainly a lot of renewed interest as of the last couple of years in it. How does incorporating AI kind of weigh into this build buy inner source conversation?
- [08:49]
A
The AI actually introduces a different way to think about the build it versus buy because it's no longer about cost and time with AI, because AI is here to speed up a lot of development. We have already seen a lot of advantages big companies are getting by adopting a lot of these large language models itself. The other factors that start becoming more relevant when considering the build versus buy in the context of AI is the first one is context itself. What is that core differentiating capability of yours as a business? And this is where you need to understand with AI, if it's a unique capability that is very unique to your success of your business itself, you should be gravitating towards building it in house, especially with AI tools because a lot of this goes to. The second part is the control over the data. A lot of AI tools need data to help you make these smarter, intelligent decisions. The question you need to ask yourself is what kind of data are these AI tools need? Is it sensitive customer data itself? Because previous build versus buy solutions would not consider a lot of this. But this is now one of the key factors you need to consider now with adopting AI tools. If the data itself is not customer data itself, let's say it's only internal to the company and operations like marketing needs to quickly build stuff, then it's easier to adopt an external AI tool. But if you need control over the data itself because of privacy requirements and making sure the customer data doesn't leak, that's another factor. Now you need to consider in the age of AI before adopting, adopting or buying one of these AI solutions itself. And then the third is the change in velocity, which is very, very relevant to AI because in the last 18 months we have seen how models have quickly changed, how their capabilities have changed and what that translates into your expectations from these products itself. 18 months ago, models could do X amount of stuff for you within 18 months itself. The capabilities and the the features these AI models can provide, what you can do has completely changed itself. So you need to catch up with this change velocity itself. Are your internal requirements changing as fast as how the models are changing? That makes you question itself, how and when to adopt these new AI tools itself.
- [11:09]
B
Want to learn more and join the discussion About Marketing and AI? Attend a premier conference dedicated to marketing and AI. That's Meikon, the Marketing Artificial Intelligence Conference from October 14 through 16 in Cleveland, Ohio. Meikon brings together the brightest minds and leading voices in AI. Don't miss this opportunity to connect with a dynamic community of experts, visionaries and enthusiasts. The Agile brand is proud to be the lead media sponsor of this important event. Register today@marketingaistitute.com that's Marketing AI Institute.com and use the code AGILE150 for $150 off your registration fee. I can't wait to see you there.
- [12:01]
C
And so what about, you know we have, we have a lot of marketers and you know, professionals, a lot, a lot of people listening to this show that are not necessarily sitting in IT or in the engineering side of the business that may be building some of these tools and yet certainly very reliant on the, you know, build versus buy decisions that are made within the organization. They might have a seat at the table but you know, not, not sole responsibility. What's the, you know, how should a, let's say a chief marketing officer or someone like that, you know, how should they be looking at this when again they may have some influence over some of these decisions decisions. But what should they be thinking about when talking with other leaders within the org that are making these build vs buy vs inner source type decisions?
- [12:52]
A
This is a classic problem I've seen. There's a disconnect between IT and business leaders itself. And a lot of this classic disconnect goes back to business leaders viewing what it delivers or what they need from it itself. In terms of projects, not capabilities. When you think about projects, you know you're requesting something from it. This is where the IT that will build it have a different complete sense of how things will be built, how they will be delivered and the business leaders that have a need and a want for it at the end from these projects have a completely different perspective and then there is a clash. The solution it is for leaders to stop thinking them towards as projects and to start thinking about capabilities. What capabilities your organization has to deliver stuff. We have reached a stage, especially with AI where non technical users have been empowered to build a lot of these tools without a lot of core technical knowledge. For them to successfully be able to build it, it needs to provide them with enough capabilities that they have visibility and to be able to understand what can they do and what they can't do. Where do they need it to be involved, where do not need it to be involved? If business leaders start looking at it as a black box, this is where the disconnect and the frustration happens. Absolutely. Once they have a complete visibility on what does my IT provide? What capabilities do I provide? What are my needs? What is the bridge between the capabilities we have and what I need to deliver? And then if there is a gap with this visibility itself, then the conversation around build versus buy becomes very easy to have with it. And you're on the same page, you're having a discussion, but if one side is looking at it as a black box and the other side is looking at it, that we have full control over what this decision is being made, then you're probably not making the best decision for your company at that point.
- [14:47]
C
Yeah, well, and then to build on that, let's talk about measuring success as well. Because, you know, I think there's, there's some, let's, let's call them traditional ways of measuring. You know, you, you license software, you buy software. There's, there's some ways of measuring success there in the, in that siloed version of the, you know, the build scenario. I think there's, there's probably some, some metrics there. How, how do you recommend measuring success of this inner source approach? And I would imagine maybe it's some of those others, but sounds like there's some other things as well. And how do these metrics compare to some of those more traditional models?
- [15:29]
A
Absolutely. With Inner Source, the first change that happens is you stop zeroing in into a specific project and its measurements. You think about the ecosystem capabilities itself. Metrics like whether the project was delivered on time, whether it was on budget are absolutely important, but they're not the core metrics itself that should drive your analysis on how your decision making went. With Inner Source, you take an ecosystem based metrics, which is reuse, velocity, collaboration. The whole idea is if I am building an inner source internally with these vetted components and a lot of effort has been put in, every subsequent project or a system I develop will be delivered faster. Yeah, Think about it. Starting from pieces of Legos, you built the first one. You rebuild a project from the first pieces of Legos, you extract more usability. Now you have more complex LEGO pieces. Another request comes in and you're like, you know what? I only need to build 40% of new Lego pieces. I can reuse from what I have done already. Let me start assembling them. And then when you measure use, you, you look back in your last quarter, you said the first project took X amount of time and X amount of cost to deliver. How much faster were the subsequent projects delivered? They will see it's less time, less effort it takes. The other key Thing to look at is, and this is something I learned working in finance itself, I call it headcount liquidity. Large organizations have priorities that change all the time because it depends on where are you in the market itself. Is this a time where compliance takes over so the priorities shift towards a lot of compliance based projects itself. So this is where what you want is your internal headcount to be absolutely fluid. You should be able to move developers from one place, one project to the other without added overhead and friction, which is extremely hard to do with the traditional way of doing things because again, everything is built in silos. Every project has a specific way of developing stuff. There's overhead and mental overhead for developers to move from one team to the other. Imagine now completely think about it. When it's an inner it's. It's built with the Inner Source initiative in mind. Every team has visibility on what other teams are building. Every project manager has visibility in what capabilities exist that have previously been built. Every time a new project gets built, the conversation changes from starting net new to how can I build from an existing capabilities and existing solutions. So if priorities change in, something's more important, it gives that headcount and fluidity and liquidity to the product manager saying, I want X amount of developers to currently to move to the new project so I can deliver faster and I'm not going to lose overhead on it. And I think these are new metrics that are more relevant with Inner Source now.
- [18:19]
C
Yeah, yeah, well, and I would imagine and you kind of touched on this, but the idea of collaboration within an organization changes as well. And so maybe if you could talk a little bit more about that, how this approach can promote the transparency and collaboration within an organization and how that impacts. You use the Lego analogy there, but how it impacts the overall software development life cycle.
- [18:52]
A
Absolutely. And the collaboration piece is one of the biggest advantages you get from Inner Source and we have seen it thrive in open source model itself. A lot of times the blockers for collaboration are a lack of visibility within organization across large teams, where they have complete lack of visibility on what the other team does, how it does, what their priorities are, from technical also to requirements based. And what are they building, who their stakeholders are, why are they building this, where did this need come from itself? With Inner Source, everything is open and discoverable. Everything is considered as a shared company asset, not your team's asset itself. And this is one of the differences I have personally noticed when we adopted an Inner Source model in a large organization where it's very Obvious to expect the benefit of collaboration to reach at a developer level because you think, oh, developers have to write less code. Developers can reuse a lot of existing code and now assemble stuff. But the real value where I saw was the change in perspective of product managers. When product managers sit with stakeholders, the previous conversation always started with, hey, what are your needs? What are your requirements? What do you want to build? Why do you want to build? And then they ask you for an estimate on how long will it take to build. And then product managers go back and look at, okay, we delivered this for you before. And based on this, this is how long it'll take. With inner Source, the conversation completely changes because when they ask there is a need, the product manager can open have a complete IT idea of, okay, but last quarter this is what I delivered for you. These were the capabilities we delivered for you. Next quarter, this is what I can reuse and reassemble from it. The conversations are happening with stakeholders. I'm giving more accurate prediction about the time to things to be built because they have more insight on what exists within their inner source ecosystem. And I think this is where transparency and collaboration provides the biggest value to product managers making these decisions, having this conversation with stakeholders and setting up expectations on delivery with them.
- [21:05]
C
Yeah, yeah, what about security risks? You know, certainly, you know, everything from data compliance to many other factors are top of mind for organizations. Does this increased collaboration increase, you know, potential security risks? Or, you know, how does an organization effectively manage things like that while still, you know, fostering all the great things, the open communication and all of the other things that this approach encourages?
- [21:36]
A
The basis of inner source and open source model is enforcing a standardization of delivery that starts off as basis for being able to collaborate seamlessly and also deliver seamlessly. As part of this consistency in how you want to deliver each component or each deliverable when it delivers has security baked into its lifecycle itself. When a team A needs a capability from team B and they realize they have insight on they can actually contribute back to team B, they also have insight on the development guidelines of team B. Team B, Team B had already automated the whole process. If you are actually introducing a change, it will go through our life cycle of security checks, automated governance checks, validations. But the other side of it is if you're building in components and building in inner source and building in these reusable modules like Lego bricks itself, think about a security vulnerability introduced in one piece of module. It's very easy to roll back because you can pinpoint on exactly where it was introduced, everything is versioned. So rollback becomes very easy compared to traditional way of doing things. Everything is being written as big pieces of code. They live in repositories. You don't know how much stuff gets duplicated. It's extremely impossible to understand what depends on what? If I change this, what am I breaking this? If I change it, is there a guarantee that everywhere this is being used it's not being rewritten? When you build on blocks, you have what we call is insight into a dependency graph of the code itself. When you have inside of the graph, what you understand from the graph is who are your dependencies and what depends on you. Once you have visibility on who are your dependencies and what depends on you isolating security fixes, it becomes very seamless. And I think this is one of the biggest advantage companies get by adopting this approach.
- [23:29]
C
Yeah, yeah. Well, as, as we wrap up here, one last thing, I want to get back to the ROI part of this conversation and looking at this from the, I would say from the non technical, maybe from the marketers or other business execs standpoint, you know, you mentioned that often it gets thought of as just deliver me this thing or this widget or. I mean, I'm paraphrasing, but how do you recommend changing that mindset and that conversation into something that's more again delivering capabilities and functions that really deliver great value to the business? Because I think what you're talking about here is companies really investing in long term capabilities that grow over time and that compound value over time. You know, how does a CMO or you know, somebody kind of change their, the way that they're thinking about how some of this stuff gets delivered.
- [24:28]
A
I think the basis of it is breaking down the capabilities into these small manageable individual pieces, not just with code, but also what value the end value it gets out of it. A lot of times, you know, this disconnect from executive leaders happens because they have an ask which is extremely big. Let's say build me a new marketing campaign page and let's deliver it. The delivery of it is not exactly how the ask happens. The delivery happens by breaking down, oh, I need a new header, I need a new action hero, I need a new action over there. Some call to action buttons I need and I need to assemble them into a page. But the executives don't see this. Absolutely. What they see is a big ask and it gets delivered. Then they have another six different big asks just waiting in their pipeline, which they have completely disconnect of how it's going to be built. So it starts with visibility. It starts with complete visibility of how software gets delivered. And to reduce that complexity of understanding how software gets delivered is to break down the delivery of software into these independent manageable pieces, whether they are code, whether they are the capabilities that are linked to the core delivered. And this is one of the things we see a BIT is every time we talk in components and component is a first class citizen we call it in our ecosystem. The reason is because a component is not just code for a developer. It has documentation, it has live previews so you can understand what it does. The documentation explains you why it is being built, what capabilities it serves, and then there's a graph of these components which connects stuff. So if an executive asks me to build a certain capabilities, they have a visibility of how it is assembled for each piece, they also have a visibility of what it does. This also makes them understand their asks and their capabilities from the IT itself. And then this is a two way transparency that creates between IT and the executives.
- [26:23]
C
Yeah, that's great. Well Love, thanks so much for sharing all your ideas and insights today. One last question for you. I'd like to ask everybody, what do you do to stay agile in your role and how do you find a way to do it consistently?
- [26:38]
A
For me personally, I'm a big believer in feedback loops. When I work in teams. I love the collaboration aspect, I love the feedback aspect. To stay agile. What I personally will do is I will break down my tasks, just how composability works and get as much feedback as quickly as possible with the right executives, with the right team, with my team members and iterate. If you have a close shorter feedback loop and you have a faster iteration on it, I believe you can tackle as big of tasks. It is not daunting anymore for you.
- [27:10]
C
Yeah, that's great.
- [27:12]
B
Well again I'd like to thank Love Kapoor, staff engineering lead at BIT, for joining the show.
- [27:17]
C
You can learn more about LOVE and.
- [27:19]
B
BIT by following the links in the show notes. And thanks again to our sponsor bit. In the age of AI don't just generate code compose software. BIT helps you create and reuse independent components to build reliable scalable applications. Stop rebuilding and start shipping with the AI powered composition platform at www.bit.dev. thanks again for listening to the Agile brand. If you enjoyed the show, please take a minute to subscribe and leave us a rating so that others can find.
- [27:50]
C
The show as well.
- [27:52]
B
You can access more episodes of the show@theagile brand.com that's theagile brand.com and contact me. If you're interested in consulting or advisory services or are looking for a speaker for your next event, go to www.gregkillstrom.com. that's G R E G K I H L S t r o m.com the Agile brand is produced by Missing Link, a Latina owned, strategy driven, creatively.
- [28:21]
C
Fueled production co op.
- [28:23]
B
From ideation to creation, they craft human connections through intelligent, engaging and informative content. Until next time, stay curious and stay agile.
- [28:37]
A
The Agile Brand.
- [28:42]
B
Before we continue, I wanted to share a key strategic resource that a majority of the Fortune 500.
- [28:47]
C
Are already aware of.
- [28:49]
B
Finding the best technology, business and talent solutions is not easy. With business demands and competitive pressures mounting, you need to be able to design, deploy and optimize your technology to provide leading customer experiences while driving business growth. Those of you that have been listening to this show for a while know that this podcast is brought to you by Tech Systems, a global provider of technology, business and talent solutions for more than 80% of the Fortune 500. Tech Systems accelerates business transformation for their customers. Whether you're looking to maximize your technology roi, drive business growth, or elevate customer experiences, Tech Systems enables enterprises to capitalize on change. Learn more@techsystems.com that's teksystems.com now let's get back to the show.