Building B2B Marketplaces with Mike Luby from LeafLink

Eric Dodds  00:06

Welcome to The Data Stack Show where we talk with data engineers, data teams, data scientists, and the teams and people consuming data products. I’m Eric Dodds.

Kostas Pardalis  00:16

And I’m Kostas Pardalis, please join us each week as we explore the world of data and meet the people shaping it.

Eric Dodds  00:25

Welcome back to The Data Stack Show, we have a really cool guest lined up, Mike, who is the director of engineering for LeafLink, which provides all sorts of solutions for both brands and retailers in the cannabis industry. And the burning question that I want to ask is they have a lot of different products and it’s just really hard to do sort of analytics, and I mean, really even software development across a suite of four or five products. And they may even have more than that. So I just want to hear how he’s approaching that. I mean, just building one product for one person is really hard. And so I want to hear how they’re doing that. Kostas what’s your one question?

Kostas Pardalis  01:07

Yeah, my question that I wanted to ask from the moment that I saw, like the websites and their product line is about the usage of API’s in the marketplace. That’s a pretty unique thing that you don’t often see in marketplaces. And it’s clearly technical. And I would love to hear about the business and the technical reasoning behind this choice. So looking forward to chatting with Mike.

Eric Dodds  01:33

Great. Let’s dig in.

Eric Dodds  01:35

Welcome to The Data Stack Show today. We are really excited to have Mike, the director of engineering for LeafLink on the show. Mike, thank you so much for joining us.

Mike Luby  01:46

Hey, thanks for having me. Appreciate it.

Eric Dodds  01:49

And why don’t you just give us …  you have such an interesting background, and I want to dig into that … but could you just give us a brief overview of your background, then what you do at LeafLink? And then what LeafLink does and the problems that they solve?

Mike Luby  02:03

Yeah, sure. So like I said, my name is Mike Luby. I’m the Director of Engineering here at LeafLink. I oversee our marketplace product. I’ve been building software for the last 16-plus years professionally worked from small startups all the way up to enterprise level companies. And you know, both from an Enterprise SaaS perspective and quite a few DTC spaces as well. LeafLink itself is a cannabis industries wholesale marketplace where we’re defining the way that thousands of brands and retailers can manage and track their orders and relationships, and they can focus on growing their businesses. It’s a B2B marketplace where those producers can meet their retail customers and buy products from each other and then build those relationships through CRM tools, and other tools to help optimize their business. We also have quite a few other areas of the product, that kind of ladder up through our marketplace, specifically our payments side, which, maybe you recently saw in the news, we’ve recently closed a $250 million debt facility round, one of the largest deals to bring liquidity to this specific market. Given all of the compliance challenges that this market has, we use this capital to support the cannabis supply chain as a whole by providing that liquidity directly to licensed businesses. We also have a shipping portion product, which we recently launched in March of 2020. To help streamline the order delivery experience for our customers, we provide a faster and more reliable delivery experience to those customers. And we continue to roll these out to a whole bunch of different markets over the next year. But it allows us to be part of that supply chain, optimize it and provide better service overall in comparison to some of the delivery aspects that they have today. Additionally, we also have our LeafLink insights product launched around the same time as our shipping product. This really provides the data insights for our customers to build, measure and deploy their brands on LeafLink. We also provide in-depth insights for each of those unique markets in terms of how their products perform, their categories perform, how they interact with the customers, how the market is overall etc.

Eric Dodds  04:24

I mean, you provide so much infrastructure and tell me if this is a dumb question, and I know this is a show focused on sort of data and technology, but I think the way that a lot of our audience thinks is they apply technology to solve business problems. And you touched on some of this, but I just wanted to ask the question directly. I mean, there are other, you know, sort of marketplace type solutions out there, you know, even generic type solutions, you know, that sort of connect wholesalers and retailers. And I’m just interested to know with such incredible growth, you know, what, what are the specific challenges that LeafLink solved or brings to the table. So you mentioned that shipping, you know, is one area where the options weren’t great there. I know that compliance in the cannabis industry is certainly a consideration. But I’d just love to know, you know, you’re bringing powerful technology to the table to solve a really specific marketplace problem and really sort of infrastructure problem for the industry. And I just love to know what problems created the demand in this specific industry.

Mike Luby  05:26

You know, I think compliance is probably the one of the bigger ones out there is this industry. So for example, the United States, obviously, is not fully federally legalized at this point. And each state has their own individual specific rules that differ from state to state. Whereas Canada, for example, Canada has a little bit better from a consistency across province perspective. So what our tool does, one, it helps with that compliance side, right. So understanding each individual state’s needs and requirements for things like the marketplace for licensing, for deliveries, financing, etc. It gives our customers the ability to really understand who they’re working with, making sure that they’re working with reputable and compliant retailers or brands, etc. And then, you know, the other side of it is the fact that this tool is specifically geared towards cannabis. So there are aspects to this tool and cannabis that are unique in comparison to other kind of wholesale marketplace and tools like it, you know, we focus on things where we have our, for a very tactical example, our testing information based on the strains of each of the, you know, different flower and products available. And then we have that information surface within the product. So they have it at their fingertips. And then we also work closely with a compliance tracking software system called Metric. So we have deep integration with that. So we make sure that, you know, all the touch points through the supply chain are compliant, and they have all the information needed to be on the level.

Eric Dodds  07:07

Super interesting. Thank you for that background. I think our listeners just appreciate the context. All right, I have a ton of questions, but I’ve been monopolizing the conversation. So Kostas, please get us back on track.

Kostas Pardalis  07:21

No, that’s a super interesting conversation to have. So Mike, like through a quick overview of the product, and actually, it’s not just one product from what I understand, it sounds like it’s a complete suite of products in order to support this market. I mean, how do you manage to have this crazy velocity in product development? Which, of course, I guess it reflects, also the growth of the market has and also the company. Can you give us a little bit of how it looks inside the company, in terms of coming up with the product ideas, developing the product, delivering, and all these things? I mean, there are plenty of companies out there struggling with just one product, how does it look in a company like yours.

Mike Luby  08:08

Yeah, I’m gonna start with kind of how we structure the product management organization at the company, because I think that really starts off and is the entry point to how we really build these high velocity teams, right. So at LeafLink, we structure our product engineering organization around our business domains. Currently, we have five individual domains, we have liquidity, payments, commerce, deliveries and our platform. Within each domain, we have several cross-functional pods that focus on key goals that drive the customer value. Each cross-functional pod consists of members from engineering, product design, DevOps, quality, all of that. And the exact breakdown of each pod in terms of the specific resources is, you know, really dependent on their specific needs. But I would say this kind of pod structure is very similar to the kind of Spotify pod-yield model, where we have these cross-functional partners. There are multiple, you know, in addition to that, I think going a step deeper in terms of velocity, there’s multiple things that we do, we are very thoughtful, and measured in terms of how we design and think about product, which then leads into also how we also think about and architect software. And then we go through our processes to ensure that that software is built to the highest quality and delivered, you know, as quickly as possible with minimal defects. Really, at its core, I think some of the key aspects that I think are very important that we leverage are: one is automation. So we have a robust CICD pipeline to get the code from each individual engineer to production, you know, as quickly as possible and without sacrificing quality. Next is accountability. And this is really across both the product and engineering, and even at the entire company level. We really hone in and focus on OKRs. We leverage that across the entire, not only product development lifecycle, but also from a career growth and development perspective, we leverage that platform and that framework to really hold ourselves accountable and deliver product and it ensures that we’re thoughtful around what we’re doing from a step function and perspective. The next is growth. And this really ties again, to the OKR perspective, but you know, specifically calling it out is making sure that the teams have the training, the tools so that they are being challenged to grow both technically and from a career development or professional perspective, as well as is key because it, it all kind of ladders up to that ownership and accountability as well.

Kostas Pardalis  10:56

How big is the team right now?

Mike Luby  10:57

We are currently around … the engineering team itself is around 30 and I think the company is around about 130 total. We have offices in New York, LA, San Francisco, Denver, Austin, Toronto. So we’re kind of spread out as of right now, but a majority of the engineering department is in New York.

Kostas Pardalis  11:17

Was it like these from the beginning? Because, you know, like many times when we talk with people, we focus too much on how the structure is today, and why it’s great, and how it helps and all that stuff. But I think it’s also quite important, like the journey to get to this stage that you are having today. So I don’t know how much of where you might be from that. But like that would be amazing to share a little bit with us, especially for a company that grows so fast, which probably means that any kind of also, organizational changes have happened fast. So how did the company look like in the past? And how did it progress to reach these very robust and high velocity structures that you just described to us?

Mike Luby  12:00

I’ve only been here for about four months, but I do have some insight in terms of how we kind of started and where we are today. Like any startup, it started with our co-founders, Ryan and Zach, they built out the team. For the last, I think four or five years the company has been around, it has been a relatively scrappy team. Within the last year, from a management perspective, the engineering team really consisted of the VP of engineering and engineering manager, the rest was more of a flat organization. Relatively recently, within the last I want to say four or five months, we started bringing on more engineering management to help us scale. Right, you know, our VP, and CTO have done a great job up until this point, but it’s time for them to focus on a lot of really strategic high-level things while we bring in more talented engineering management to make sure that we are growing and building today.

Kostas Pardalis  12:56

So let’s move to the technology. Can you share with us a little bit more information about the stock that you are using, and also if you can give us an indication of infrastructure and the volumes of requests that you have to work with. In general, like give us a bit of more color into what it means to build this product and also to operate from an engineering perspective.

Mike Luby  13:19

So at a high level, we are in Amazon Web Services. We’re a containerized application leveraging Kubernetes. We are primarily today a Python stack, leveraging Vue.js on the front end. We leverage Postgres, Redshift, Terraform as well. That at a high level is pretty straightforward. We are continuing to invest in bringing more newer technologies, more newer capabilities within our technical stack. We are driving towards adventure vin and service oriented architectures as we continue to accelerate over 2021. One thing I specifically do want to call out though, is what I find really, that I appreciate the most after joining LeafLink is that our CICD pipeline is pretty robust. I know that kind of sounds like a silly thing or a table stakes. But based on my experience at you know, larger companies in the past, LeafLinks’ CICD pipeline is kind of top of the line where we can quickly get that code, the work from an engineer, get it to production pretty automatically, you know, making sure we have the quality in place and whatnot, so they can see their, you know, their efforts in production in customers’ hands pretty quickly. I think that’s pretty rewarding.

Kostas Pardalis  14:38

Yeah, that’s great. And I think not every engineer out there is going to appreciate the value of having like a robust CICD pipeline there. I don’t think that anyone can disagree with that. I want to repeat the same question that I did about the organization and how it changed. But this time around the technology. I know that as you said, like you’ve been there only for like four months, but how do you think that as the company matures and the product matures, the technology is also changing. What was the process and what technologies, for example, you’ve introduced now, and you didn’t have in the past. And this was also like the result of having the growth that you have, and having also to build and maintain the structure that we talked about earlier.

Mike Luby  15:20

So at the very beginning, and then like any company of this size, and who are growing, there are still, you know, one could say, technical debt aspects of it. But at the very beginning, we were a Django Python application, you know, the standard, you know, you hit a page, it loads the templates, it renders data, you click submit on a form, it sends the data back and just kind of refreshes the page. From there, we started to introduce, you know, the single page application kind of technology. So bringing in Vue into the stack. As we are continuing to scale out the organization, as we are continuing to, hit the product market fit, and deliver functionality that customers really want. We’re introducing the new technology. So we’re bringing on more and more managed solutions from Amazon. Really one of kind of the mandates is like what does Amazon provide from a technology perspective, from a managed solution perspective that we can integrate into our platform, so we can continue to accelerate our development. So one of those things is DynamoDB. For example, we’re pushing towards leveraging Dynamo, we’re pushing towards leveraging Amazon’s Lambda functionality and serverless, their EventBridge technology for event driven architectures, etc. We have a very robust containerization of our platform, you know, like I mentioned, leveraging ECS and Kubernetes, and whatnot, our DevOps team is, you know, top notch, they do some excellent magic on their end.

Kostas Pardalis  16:59

That’s great. You said that you are moving more and more into leveraging AWS technologies. This has the side effect of a much stronger locking inside a vendor, right? Do you think that this is like some kind of risk, and also based on your experience, not just like in LeafLink, but also other large companies that you work before, this vendor lock in with the cloud and like all these also movement towards like a multi-cloud environment and all that stuff? How important do you think it is? And how much do you think like, it should affect the decisions from an engineering perspective?

Mike Luby  17:29

Over my experience in … and I didn’t touch on this earlier, but I’ll touch on now. You know, I worked at Salesforce and worked at Nike, so pretty large systems overall. My personal opinion is that, yes, I agree that there is in theory, vendor lock in. And that is something you know, as a business you should consider and think about. But I think that, you know, from my experience, the Amazon services that they provide are pretty robust, and are top-quality solutions that, you know, if you are to switch, I would be hard pressed to say, there is another, you know, technology stack out there, that more infrastructure stack out there that would, you know, be really apples to apples to them. They’re in my opinion, you know, best of breed right?

Mike Luby  18:18

Now, I think that you can, as you’re going and building your technology or application logic, your business logic and whatnot, you can account for potential vendor lock in and abstract out some key areas. And in terms of, you know, in case of glass break here, kind of situation where you need to move, but I think, you know, there has to be a balance there as well, because, you know, the chances of that happening are probably pretty slim. So why spend the extra effort to do that? You know, from my experience, Amazon provides a lot of great stuff. I know, I’m kind of sounding like an Amazon salesperson at this point. But you know, it really does do everything we want, and you know, in previous organizations we worked on Google Cloud and on prem solutions, but Amazon has always been the kind of the gold standard in that.

Kostas Pardalis  19:12

Yeah, yeah, absolutely. I mean, I know that usually the multicloud, like partly might think it’s something that you hear about really large enterprises, because they have like their own reasons and politics and compliance that they have to consider like this kind of architectures. But it’s very interesting to hear about this also, like from the perspective of an engineer and what that means for the engineer. That’s the whole thing about products, right? Like, if it makes your life easier, and you’re happy with it, why you should change it anyway. And yeah, I agree. AWS is probably I mean, they started this whole thing right with the cloud and the infrastructure as a service. So yeah, I think it makes total sense. They have like almost everything that you will need out there. Sometimes it reminds me I think, who said that, like I had a friend who was giving this metaphor that it’s like a supermarket of technology, you know, like there’s just everything there. Probably even like their own employees don’t know about all the different products that they have at the end to offer at AWS.

Mike Luby  20:10

I think it was a smart move a long time ago when Bezo’s is like, you know, develop technologies and products that we can then resell. Right. I think that was the right approach for Amazon. And, you know, I think after all these years, you could see that it’s, you know, it was the right choice, right.

Kostas Pardalis  20:27

Yeah, absolutely.

Eric Dodds  20:28

Kostas, if you don’t mind, I have a question burning in my mind. Like, I’m interested to know, you know, we’ve talked about sort of the software development lifecycle and team structure in terms of shipping software, across multiple products. And one of the implications sort of downstream from shipping the software is sort of the data and analytics piece from having multiple products. And I know, just from working with, you know, some of our customers and just past experience, that, you know, it can be really difficult to sort of understand product usage across multiple products. I just love to know, from your perspective, how do you think about that from an engineering standpoint? And do you do any work around sort of servicing the teams that are running different products? And then is there an effort or existing sort of infrastructure or workflow around understanding the sort of product usage across multiple products?

Mike Luby  21:31

Yeah, I think that is a critical part of I think one of LeafLink’s successes–leveraging how customers use the product, not only from, like, a usability perspective, but also from how they leverage it and use it for their own success, right. That allows us to be, you know, very data driven, and understand what will potentially work and use that to define new features and new workflows for them to be successful. You know, as you kind of alluded to, there’s a challenge across multiple products, there’s a challenge in terms of what you know, for example, like, what is a user in product A versus product B. You know, there’s, you know, if you have a unified authentication layer, then great, you know, you can say, okay, let’s, let’s limit down to, you know, the user IDs, for example. But then you also potentially run into their personas, right, so smaller customers, right, the same person who is doing the logistics side is also the sales rep, who is also the CEO, who’s also the guy who is, you know, the marketing team. So like, each persona also has like a different usage. And really understanding the company size, how they function, what they’re doing is critical and having the infrastructure in place to pipe all that data. And then, you know, I’m very fortunate to work with some people on the data team who are super talented, they go above and beyond when it comes to the data science side of this and really understanding and really thinking about how the customer functions. And then surfacing that with, you know, our cross functional partners, right, our product organization, our sales team our marketing team, so that they can be successful as well.

Eric Dodds  23:18

Sure, yeah, it’s just interesting. Just looking at the suite of products, I was thinking, Okay, if you have a larger organization, then I’ll use your example, the person who’s working on the logistics and shipping is different from maybe the person who’s using the advertising product, for example, right. And those are two different personas within the organization. And so you’re capturing this data. But when you think about even simple metrics, say, like, you know, an activated user or something, the definition of those things, you know, likely change from product to product, just because they’re doing very different things. And they’re very different sort of, you know, user journeys within the product. That’s really interesting, and actually really cool to hear that that seems like a competitive advantage for you that you have all that sorted out, because that’s really, really hard work.

Mike Luby  24:05

Yeah, you know, I think it also kind of plays into defining the appropriate KPIs. Right? What is the success metric for each of those personas? And then that helps you hone in on what it what does success mean for the logistics persona? What does success mean for that marketing, persona, etc. And so that way we can, you know, tweak and hone in on on the appropriate functionality for them.

Kostas Pardalis  24:27

You mentioned on some points, Mike, that you’re moving towards implementing event sourcing. Is this correct?

Mike Luby  24:34

Yeah. Event-driven architecture is what we’re moving towards in some areas.

Kostas Pardalis  24:38

Yeah, that’s, that’s very interesting. Like, can you share with us a little bit more information around like this choice, why you want to move towards that.

Mike Luby  24:46

So while we have different areas of the product, right, like, as I mentioned earlier, like the weekly platform really focuses around the marketplace and then the other products are our key pieces of that. One data model that specifically applies to all of those areas, for example, is orders, right? Where whether that is a retailer going in and creating an order with a brand, and saying, hey, I want this, these products, these flowers, etc., or it’s the other way around, whether there’s a sales rep relationship with their purchase, you know, building this relationship directly with the retailers, etc., there’s still that order model, right? Then that is applied to financing in terms of, you know, capital and making sure that they can leverage our, you know, debt facility round to, you know, have liquidity in the market, etc. And then going to the logistics side, it’s an order needs to get shipped, right, we need to receive the product from the producer, we need to have it in our warehouse, we need to make sure that it gets shipped on time and delivered on time, to our to the retailers, right. All of those things revolve around that order data model, an event architecture, or event-driven architecture will allow us to have different triggers and different sources of change within our entire platform. So you know, it would be a large undertaking, if we had all of our engineers touching the order model, right, it could get pretty hairy, because when engineer might, you know, tweak it. So it’s, you know, optimized for the marketplace, where the other one that’s going to tweak it for its optimize for logistics, and the other ones, finance etc. Having a domain owner of that order allows a single source of truth, which then allows kind of the ownership there, where the other aspects of the platform are the customers to that data model, right. So that event architecture allows, in some cases, a fire and forget type of use case, where, hey, you know, we are on the financing side, a user is a customer is making changes to their net terms, maybe they’re getting extension, maybe they’re making a payment. So we’re gonna send an audit log data, we’re gonna store data around that change, and we’re gonna fire it off and forget about it, because it doesn’t necessarily affect day to day work, right? Whereas let’s say, the logistics side, it’s a little bit more important, right? Where we’re gonna fire that saying, okay, we picked up the product, we packaged it into totes, it’s ready for delivery and we’re just waiting for the driver to come by and pick it up. All those notifications get funneled back into that order. We have that up to date in real time. So then we can show visibility through the entire platform as well.

Kostas Pardalis  27:39

Oh, yeah, that’s super interesting. And makes a lot of sense, to be honest, especially when you have so many different products that they have to operate. I mean, think about adopting such a model, like there’s much more agility in terms of like iterating, coming up with new products if you need to. I think it’s pretty interesting. So have you already implemented this? Or are you in the process of doing that?

Mike Luby  28:00

Yeah, we’re in the process of rolling this out. Right. The challenge is, you know, service-oriented architecture, event-driven architecture is relatively, not necessarily new, but it’s new to a lot of engineers. So part of that is making sure that we train our engineers in how we think event architecture, event-driven architecture or service-storage architecture should function, setting up those guardrails, right, so that they can have room to explore and learn. But it’s still within these these high level guardrails in terms of meeting our strategic vision of what those things mean. So it’s a thoughtful process, like I mentioned earlier, we’re very methodical about how we deliver a product. So it’s a thoughtful process in terms of making sure that they’re trained up, making sure that we have the appropriate architects, we have the the guardrails in place to make sure that it’s hitting our strategic vision, etc.

Kostas Pardalis  28:54

Yeah, makes sense. So you mentioned that you’re a Python shop, right? So in data, you’re also like hosted on AWS, in terms of like technologies, frameworks, and infrastructure, what have you been using to enable these new products inside the company. And can you give us a couple of tips, like from your experience with that transition so far?

Mike Luby  29:13

Part of the move towards more service and architecture is these decisions around what framework are we using, what specific technologies we’re using. It’s starting to become a little bit more minimized, right. You know, as I mentioned before, at the very beginning, we’re a Django Python shop, right. Now we have Flax services, we have Django services, we have Lambda functions that don’t leverage any framework, right? Because it’s a function as a service, right? So those decisions are becoming more minimized, we’re gonna start to bring on different technology stacks, in terms of node, especially like in the finance realm is, is a really popular tool in finance technology, that a lot of engineers who had that experience, have experience in node, right so like, it makes sense. For us to bring that technology into our platform, one for recruitment perspective, right? Because not everybody’s a Python developer. But you know, there’s a lot of other developers out there. And then also, the way we think about it is around, like, what’s the best tool for the job? Right? You know, do we need more kind of a web stop get real time functionality so that customers can see real-time statuses of orders? Yeah, that makes sense. So let’s focus on a node tool that leverages WebSockets. In the Amazon world, they have, you know, another implementation that is leveraging API gateways, relatively new WebSocket tool, where you can back it by a lambda function. So you could write it in Python, right? There’s a lot of tools out there that that we can leverage that we’re moving towards.

Kostas Pardalis  30:47

Yeah, these are all great advantages of following such an architecture. Do you see any drawbacks to that? Usually, in life, everything’s a trade off. Right. So I would assume that there is also like a trade off there. What do you see as the trade off?

Mike Luby  30:59

Obviously, there are technology trade offs and there’s people trade offs from a technology perspective. I guess they’re all kind of tied to people as well. It’s like, do we have engineers who know, the new technology, right? Like, just because we have one engineer doesn’t mean we should actually move towards that specific technology? Because, you know, the whole bus rule? And if they get hit by a bus, then we are left with nobody who knows? You know, Fortran at the company. That’s not a decision. Right? Yeah. So I, those are part of technology decisions. So being thoughtful around what new technologies we’re introducing. The next is around training, you know, you can read blog posts about the proper way to do service oriented architecture. Right. And people could take those blog posts and like yeah, we got to do it, but they don’t fully understand the ramifications of that. So really having engineers really focus in and understand the ramifications of each technology choice and why to do it, or why not to do it is critical. So making sure that training is there. Because we can get into a path where where we have a whole bunch of half solutions that because of blog posts were, you know, good ideas at the time. And then we had this disjointed crumbling platform.

Kostas Pardalis  32:12

Right. Makes sense. Makes sense. One last technical question before I let Eric ask his questions. I noticed on the website that you have invested heavily on exposing API’s. To be honest, I find it this very interesting for a marketplace, most of the marketplaces, I know that they don’t invest that much in creating an environment where their customers can integrate with, that’s more of a business question that reflects also like on the engineering side of things, but why did you do that and what’s the value of having something like this?

Mike Luby  32:47

Yeah, I think, you know, having API is definitely critical to our customers. You know, as I mentioned, our platform, we have, you know, 1,800-plus brands, 5,700-plus retailers, ranging from smaller, like mom and pop shops, to large multi-state operators, right. Our API’s provide critical integrations to help those customers automate and optimize their businesses to be more successful. Right. You know, I think that building a developer ecosystem, and evangelizing those API’s is critical. So that they, you know, not only are those companies successful, but in return we think is successful. Right. You know, as they say, every every company is a software company at this point, right? And you know, where they can automate things away, where they can focus on those critical value ads, right? It’s kind of like, you know, delegation at an engineering management perspective, you know, where you can automate and save some time, like, you can then use your leadership capital in other areas, for example.

Kostas Pardalis  33:53

How do you see the adoption of that, like, from smaller customers that you have? Because from what I understood, from what you mentioned, you have like every size of companies that you direct with as customers. So I would assume like bigger companies, like it’s much easier for them like to employ your like, have some even subcontractors like to work with that. But with smaller companies and shops, for example, did you see like adoption also there to the API’s that you expose? And how do you see this working actually?

Mike Luby  34:20

Yeah, so we have a API, public API and integration team as well, here at LeafLink. So not only, are we here to help serve the larger customers through those public API’s. But we also have other organizations, in one case, other organizations that are building integrations of their cannabis specific technical products that are leveraging API’s against LeafLink product because their customers are also our customers. So it makes sense from an integration of a kind of third-party vendor perspective. And then we also on the smaller integration side, those smaller companies we’re seeing are leveraging external things like marketing tools or you know, additional different CRM that we have integrations with. And we leverage, you know, appropriate workflow tools to push data between and sync data between those third-party vendors and our platform as well.

Kostas Pardalis  35:13

That sounds great. I find it very interesting to be honest, like, extremely interesting. I have some stories from other marketplaces where they were trying to like to do something similar in the past, like a couple of years ago, and it was a big part of the work to be done to figure out how we can help smaller shops, for example, to integrate with our platform. But anyway, that’s a discussion for another day. Eric, he’s all yours.

Mike Luby  35:36

I just want to just touch on one other point, one of the other benefits is that, you know, again, going back to the compliance side, there are multiple markets that leverage Metric from a compliance perspective. Those integrations are critical for the small companies, larger companies to have those integrations, because in a non-integrated world, you have, you know, multiple sheets of paper that people have to sign and, and work through from a logistics perspective. So this is just another great benefit of our integrations and APIs.

Eric Dodds  36:08

Well, Mike, we’re getting close to time here. So we’ll end with a question, you know, I’m constantly thinking about ways that we can help our listeners, especially when we get to talk to someone like you who has such a, such a diverse background working at some huge companies. So the question I have is, you know, you’ve, you’ve worked at Salesforce, you’ve worked at Nike, LeafLink is, you know, obviously smaller than those companies but growing at a really fast clip, I just love to know, working at really massive organizations like Salesforce and Nike, what are some of the lessons that you’ve learned about scale, that have stuck with you or, you know, that sort of formed the way that you think about building software? You know, especially at an earlier stage company?

Mike Luby  36:56

Yeah, some of the, like, the first things that kind of popped into my mind are around, you know, keeping things simple, right? The whole, you know, KISS architectures, right? Where trying to build an abstract these things out or pre-optimize, has caused more issues in the future than that were helpful, right? Abstracting away functionality, because that’s how you do it in Java, or, you know, building multiple layers and building a  non-scalable layer on top of a, you know, serverless highly scalable system, in theory, it may make sense, and, you know, you’re setting yourself up for great innovation three years down the line. But today, you’re not serving your customers. Right?

Mike Luby  37:46

So like, you know, kind of how I how I think about and how I, you know, what I’ve learned over the years is like, yes, have an eye towards the future, right, understand where, where you want to go strategically. But really, you got to build for today, right? So that that eye towards the future will inform what you’re building today. But you really still have to deliver value, you have to build the functionality for your customers, prove that, you know, your product works, you have product market fit and all those great things. So you can then in the future, scale it out and build those really, you know, artistic solutions?

Eric Dodds  38:18

Sure. Yes, artistic is such an interesting way to put it. And I think if I had to distill that perspective, into a word, I would probably choose mature. And it’s interesting to hear you… Yeah, I think the word nuance can be overused. But the concept of looking into the future and being informed and the difference between being informed about the future and building for today, and building for the future does sound very similar, but there’s a significant difference. And one thing that comes to mind Kostas that we’ve heard other guests on the show talk about is this concept, almost of a boring stack, you know, where they say, you know, our stack isn’t crazy, but that’s because it works really well. And it’s really reliable for our customers. And that’s the most important thing. So really neat to hear that perspective reiterated.

Mike Luby  39:13

Yeah, exactly. I, you know, I agree with that, fully. It’s that, you know, when it comes to engineering talent, or, you know, time and experience like that is the artistic part of what we do is is knowing that nuance between, like, like you mentioned, building for now with the eye toward the future or building for the future, right? That’s, that’s where you can find those really talented engineers who can do that, effectively.

Eric Dodds  39:41

Sure. Yeah. It’s as watching a talk from a founder. I can’t remember exactly which one but they talked about this, you know, innovation, looking into the future and imagining a different world. And he said, that’s really cool for building new types of technology but not great for building a business because you know, people aren’t ready to buy them. Yeah, that’s a really good point. Like, you know, there are people who have real problems right now.

Eric Dodds  40:06

Well, Mike, it’s been a pleasure to have you on the show; we’ve learned a ton. That sounds like you’re doing really incredible things at LeafLink, really, in all regards, but especially in the software development lifecycle, and we’d love to, we’d love to catch up with you down the line when you’ve had a little bit more time in the saddle there and hear how things are going.

Mike Luby  40:26

Excellent. And thank you for having me on. I, you know, I look forward to seeing if there’s any questions if anybody wants to reach out and get in contact with me, feel free. Looking forward to all that. And thank you for having me on. I appreciate it.

Eric Dodds  40:39

Well, that was a great conversation. And I’m glad we got our top questions answered. I think one of the things and I’m probably going to repeat this a lot, because it’s a recurring theme, is this concept of keeping it simple and almost having a boring stack. I thought that the way that Mike described having a simple stack, and the value of that for your customers today was really well-said and I think just points to how mature he is, after having such a vast amount of experience at all sorts of different huge companies.

Kostas Pardalis  41:11

I found extremely interesting, actually, the conversation that we had about my initial question. It is amazing to hear from a company that is building marketplaces, which traditionally, they’re supposed to be not very technical in terms of the products that they expose. And having Mike actually saying that even small shops are software companies today, and they need to be if they want to survive. That was a great insight. And I’m really looking forward to seeing how this is going to progress in the future because I think we will see more and more products like this, that there are more consumer focused and not technical to become more and more technical in order to deliver value. So looking forward to talk with him again in the future into what’s going on and what’s new with LeafLink and Mike himself.

Eric Dodds  42:01

Me too. Well, thanks again for joining The Data Stack Show. Subscribe to get notified about new episodes on the platform of your choice and we will catch you on the next one.