Taking the Busy Work Out of Building Data Pipelines at Scale w/ Chris White

ABOUT THIS EPISODE

Within a year of the first prototype, Prefect had their first paying customer — a Fortune 100 company. Their SaaS offering was not even publicly available yet.

That was partly because they were developing a platform that allowed companies to build, run, and monitor data pipelines at scale, a problem no one else had tackled in quite the same way.

Another reason was their commitment to the iteration cycle during development. By releasing the MVP early, they were able to gather feedback immediately and improve the product with incredible speed.

In this episode, Prefect’s CTO Chris White shares the challenges they encountered and lessons they learned along the way.

We discuss:

- How Prefect helps developers run and monitor data pipelines at scale

- Their strategy around open source

- Intentional choices made during their development journey

- Building a culture that embraces mistakes

Check out these resources we mentioned during the podcast:

- Find design books by Sandi Metz at https://sandimetz.com/products 

- Find Creativity, Inc. by Ed Catmull at https://www.creativityincbook.com/about/ 

Want to hear more stories from high growth software companies? Subscribe to Application Modernization on Apple Podcasts, Spotify, or check out our website.

Listening on a desktop & can’t see the links? Just search for Application Modernization in your favorite podcast player.

You are listening to application modernization, a show that spotlights the forward thinking leaders of high grows software companies. From scaling applications and accelerating time to market to avoiding expensive license and costs, we discuss how you can innovate with new technology and forward thinking processes and save some cash in the process. Let's get into it. Thanks for listening to Shattusoft's application modernization podcast. I'm your host, Nick Marcarelli. The goal of this podcast is to focus on speed, scale and savings related to the stories of high growth software companies. Today I'm speaking to Chris White, the CTEO prefect. They help customers build, run and monitor data pipelines to scale. Our conversation will cover how prefect came about building teams and technical inflection points in the development of their offering. Thanks to red hat for its continued support of the application modernization podcast. Hey, Chris, thanks for joining us today. Yeah, thanks for having me. Neck happy to have you. So we came across your your organization, and I was like, this is this is the type of people I'd love to talk to. And you know, we had a quick conversation and sounds like you're doing some really innovative work over your organization. So why don't you give us a minute explanation of what you guys do and what you're trying to solve for customers and will have advertisement on? Will you do a prefect? Sure. So the really short version is prefect allows developers, especially in the data space, to build, run and monitor data pipelines at scale. That's the like the headline, but kind of getting a little bit more into the weeds, what that really means is we provide things like highly configurable scheduling of Pipelines, observability of Your Business Logic, so you know the different tasks that might make up a workflow, and then a lot of other features that we usually frame as negative engineering. So kind of a way to think about that is it's essentially all of the Defensive Code that people end up writing and the defensive infrastructure that people build them in order to anticipate unknown failure modes. So, for example, you might put in a bunch of logging because you're not sure you know where in a task something might go wrong. Prefect essentially handles that all for you kind of out of the box, so you can focus on writing what we would consider you know, the innovative code that you're really hired to do. SPRINKLE in a couple of prefect idioms throughout and you know you're essentially good to go to productionize your data pipelines Gosha's. So you kind of take all the hard work out of building and maintaining that infrastructure specific to running day too pipelines and being able to extract useful information from all the data. Yes, and there is a little bit of a catch that's probably worth calling out, which is that we don't actually manage infrastructure for you, and that's actually a feature and you know, we can get a little bit into that when we talk about some of the challenges we've overcome. But Prefect, you still own your execution environments where your pipelines are running, so that's totally on you. You can lock them down, you know, however, you need to for your operations, and they communicate with our API to essentially send and receive instructions, bits of Metadata that you might find informative in our Dash Boards that you can query and filter things like that, and so so, yeah, it's a big part of it is this observability piece and then kind of underneath there are a lot of these other things, like scheduling, cashing, for example, so efficient, you know, detection when it tasks, doesn't actually need to rerun things like that. Got It. And Yeah, and the way the way it's built, this is probably also worth falling out, is we have an open source package that's written in Python, and so that's how, you know, integrate prefect. It's very much a code first solution, so...

...you can write completely arbitrary python logic and then put prefect around it. Our focus is very much on the data space, but in theory there's nothing that would prevent you from building, you know, essentially anything with reefect. I mean we run slack bots internally using prefect just because it's fun. That's interesting. So are there any kind of commercial use cases that your customers are using outside of just applyipelines? Yeah, actually, at least. So. The most interesting one that's top my mind lately, I've just been interacting with them a lot, is orchestrating the building of various python packages across diverse operating systems and different machine types, and so that's a type of scheduling that's not necessarily time based. It's location based, quote unquote, where you know, you have one workflow you want to parameterize by machine type and then actually have it run on the different machine types to build these package artifacts and and this team uses prefect to manage those pipelines and to, you know, monitor them and etc. And kick them off interesting. So would you say that the way you, you guys, have designed or software is allowing customers to do that, or is that something you have like, Oh, we could probably do that, let's go build a feature on this, or some kind of your approach? Yeah, that's a really good question. We try really hard to strike a balance, and I mean I'm sure everyone does this to some extent, right between what we know our immediate user base is, and that's the data community, but making sure that the concepts are and abstractions that we build are general enough so that our users, you know, can can kind of reconceive their world and prefect landscape and build more interesting things. So I think for for us, something that we talk a lot about internally, is just like getting the right abstraction whenever we're building a new features, so that we're not overly penning to one use case, but we're still, of course, satisfying some concrete use case, but with the ability that it might get extended by the community and interesting ways that we can predict Gosha. That's pretty cool. Yeah, it's very fun. So when what did you join prefect? Where you ground floor? Did you join recently? I was ground floor. So I've been with prefects since day one. It's about three and a half is years now. It was the first higher with a CEO and founder, Jeremiah, and essentially, you know, built built the platform bolt open source package with with him and now, of course, oversea development etc. Gotcha. So so was there a strategy around open source or is that like just your preference where you came out of and you're like we're going to do this open source? Like, can you talk us through some of that? There's a lot, a lot of data, data tools. Did a platforms. A lot of them are proprietory. They maybe even start with open source and then they get locked down and they become this fremium or, you know, an open core. Kind of walk me through some of that journey as much as you can. Yeah, yeah, this is is an interesting topic. So one thing that's a common misconception about prefect is that we were first and open source package that we then decided to build a company around. And that is not true. We had a business plan. Now, don't get it wrong, we've changed it multiple times, you know, as we learn new things, but we had a business plan before prefect was ever open source or a patch to license. So we thought a lot about you know, why are we doing this? What are the benefits? What are the risks, things like that, and a big part of it is pure ethos. We believe in open source software. We believe in the power of open source software to create, you know, powerful communities that help each other. So that was a big part of it. Is We wanted to create one of these communities and do so, you know, in the healthiest way that we could. So, I mean, anyone in our community, think will tell you that our it's a very upbeat, positive, helpful community, and that is really been a focus of ours, is making sure we can maintain that tone...

...so that everyone feels welcome and they can get their questions answered efficiently and, you know, learning about our product efficiently, and we really try hard to ask ourselves. There's there's a difference between the code that we write and the value that we deliver, and so the more code that we can put out into the world as open source code for people to build on, extend and work with, the better, you know, the value that we deliver. Especially two things like enterprise companies, are largely around security and off and things like that, and that's not something you know. That's stuff that we keep proprietary for a lot of different reason, but one of which is so that we can take a very strong, firm opinion on what it looks like and, you know, keep it to the quality standers that that we want it to be at. Another thing too, on the open source front that I think is important to note is we have a really strong opinion, and I don't think this is controversial at all, that any developer tool you need to be able to debug it when it goes wrong, and open source is an incredibly powerful way to aid in that. So you can look at a traceback, you can go into the codebase, you can find the line of code that aired out, you can drop your own print statements in it, because you can fork it and you can, you know, essentially get yourself so far and then prefect cloud, which is the the SASS offering that we have, is essentially an API, and so as long as we document those that interface and the rules for that API, well, we have really good covering so that users can self debug and I think that's incredibly important, especially given our value prop that, you know, we're trying to take care of that defensive coding for you. Right, that's that's interesting. You know, you know we live in open source. Every day you're shout us off. So that's where we start our business, where we continue to make investments with customers. So it's interesting to hear why, as a product company, because we're not a product company, we're an integrator, to hear why you why you would make those types of decisions, because at the end of the day, we have to advise customers on what their strategy would be for whatever it is, whether it's, you know, analyzing data or shipping things worldwide. And you know, well, we can make decisions that help them take advantage of an offering and and think more about what they delivered to customers and it's transparent and it's open. They win, right, everybody really wins. So yeah, I agree. Tell me about what was the bug to start prefect? Yes, like we're where did you guys arrive and you go, you know, there's a thing out there that we need to do for for people, maybe for us and then eventually for people. How did you guys arrive there? What's the story there? So there are a few different milestones here. I think the biggest one in the most central one. It really starts with Jeremiah, the founder. He was on the use on the original PMC for Apache Air Flow, which is, or was a really popular open workflow tool that came out of Airbnb many years ago, and so he was a part of getting it into the Apache Foundation, etc. And he has a data scientist was really trying to push the limits of air flow and understandably he kind of had to give up on that. He wanted, for example, in memory, data passage, paramaturization, running things at scale, so potentially hundreds of thousands of tasks, and they end a given a workflow and air flows architecture it was designed for a dope. It just does not support that in any way and you know, he definitely poked at it and tried, but it kind of fell fell on space and so he started building this prototype purely for himself inside his company that handled some of these things. So it definitely wasn't production ready, but it was just kind of a little proven concept and someone in his net network essentially said Hey, that looks really interesting, I would invest in that. and so kind of very organically, he started considering...

...that, looking around, deciding, you know, if there is actually a problem to be solved here, and there is a resounding yes. Airflow is very popular, as I'm sure a lot of people listening no, but there are very few people in the world that enjoy airflow. They use it because they have to, not because they want to. So there was definitely a problem to be solved. A ton of features that air flow just could not support in the day to workflow space. And so, you know, with that prototype he started chopping around and then he found me because I had written some blogs on desk and we really wanted a native dask integration here, and so we started started talking, ripping ideas off each other and very quickly, you know, landed on this kind of negative engineering concept and then went full bar with that. So scratching your own niche as most things. Yeah, right, it's like this isn't exactly exactly see if I can do something a little different and Oh hey, there's the thing, here's a company, here's a there's an idea. That what Hell people, and you know, maybe there's a business around this. So that's really cool awesome. So why don't, why don't you tell us a little bit about maybe the journey around how you guys are developing your software? Maybe like a short history of we started here, and probably for the technical in mind, sometimes we're a little abstracted away from like the deep technology, and I'm not an engineer, so be gentle, but sure, sure, but you know, maybe the high level concepts, if you know we started doing things this way, and maybe the pivot point you had along the way where, you like, we had to make a different decision. Yeah, so our journey has been very interesting and I think the story I just told you about how prefect even came into existence is a theme, which is that we have kind of succeeded despite ourselves in a certain sense, and that is not meant to pat ourselves on the back. I'll explain what I mean by that. I just think that we are viscerally solving a problem that no one else has focused on in the way that we're focusing on it. And so, for example, our first paying customer was a fortune one hundred company and it was before we ever had an actual public sass offering and there were just kept saying we want to pay for this, you want to pay for this, and we literally had to tell them there are certain buttons you cannot Click because you might break something, and they were totally fine with it. And so they became our first paying customer and it was before we ever even had had any plans for that. I mean we were still very much in the early days, but the observability, scheduling and just the user experience of building and scaling work clothes was enough for them to want to engage with us in a formal way, and so a lot of our history has kind of been like that. And so one of the pivot points that were actually under going now, and they can tell you a little bit to all some of the other problems that we run into, but we have three and a half years of essentially hard one knowledge from our community of what features and you know, how the aergonomics of how people expect these things to work, and we are kind of revisiting a lot of our core product assumptions and don't want to say re architecting entirely. That might sound scarier than it needs to, but but essentially re architecting how prefect work close are are built and executed to satisfy this three years of use cases that we've seen that are kind of on the edges of what we're capable of right now. So that that has been, yeah, a big focus of ours lately and a part of this is kind of how we like to develop, especially in the early days, where gaining knowledge is really the most important thing for us, and so we really like to release, you know, get a lot of feedback from our users, figure out what is the common pattern here of what our users are saying they need, our want, and then figuring out some minimal version that we know we can support. You know, it's definitely a real feature, but also still minimum viable, not necessarily like fully fleshed out. Get it in the wild and see does that resonate, does that...

...actually solve the problem, and kind of continuing to do that. And, no surprise, when you do that for a long time, you do end up with a little bit of a patchwork that might not always come together in the right way, and so that's kind of where we're trying to revisit and come up with a much more principled approach to what our software looks and feels like, and you can definitely expect to hear some noise about that in just a few months. More interestingly, I guess, on the technical side, we had an early advisor, and this was when we were first specking out the business model, before prefect was ever open source, who essentially said, I really like this problem they or something. It makes a lot of sense to me and I could definitely use it. However, I already have a text st act and I really don't want to bring in some other new technology into my text St Act that requires me to like re architect my own things. So that's the first challenge. The second challenge is, but I also am not going to give you either my code or my data on any sort of manage service because I just have extreme security requirements, I'm in thin tech space, etc. And he said, so that's the problem that I give to you, and we thought for a long time like yet, does this make sense? Is this a complete nonstarter? Is this even possible? And this is when we came up with what we call the hybrid model. For Prefect. It's not particularly informative name, but the idea is it's this open source python package that's the client. You build your workflow using that. You can test it, run it locally, but anything involving state or statefulness goes through an API and kind of one of the key inside sites is that all orchestration, retry, cashing, all of that stuff can operate on very mild metadata. So we might need things like file names. So there is, you know, a little bit that we will get, but we don't actually need the data that stored in that file to know that, Hey, this task is rerunning. It actually can pull a cash value and that cash value is located in this location. We prefect do don't have access to it, but your client code does, so it can get that location from the API, pull it locally into memory, etc. And that was actually a really hard problem to solve initially, was how can we do this so we don't even see your workfloat code? And anyone who's summary The prefect knows that we have all these concepts of flow storage and things like that and a prefect agent and all of that is in service of this separation between execution and orchestration, observability and there are a lot of really hard problems. So, just as an example, how do you detect process death whenever you don't have a route into someone's execution environment? And the answer not particularly surprising but takes a while to figure out how to do efficiently, which is you send heartbeats and if the heartbeat stops, then you know something's gone wrong and you need to tell the agent to try to resume the workflow or check in on it or something like that. And there are a lot of other kind of chicken and egg problems like that with your flow code. So how does the agent know where to find your workflow code? A, because we don't have it. You you put it somewhere, and making sure that our versioning behind the API matches the versioning you're doing client side. Just a lot of things like that that were Le so, being honestly, compli be tricky. Yeah, yeah, yeah, it's and I could see how that could resonate with certain tops commercial customers. You Know Fintach, obviously you know everybody's worried about a big one. Yeah, everybody's worried about like how much, how much access do you have to my data, which is my livelihood as an organization. It's it's private, it's Pii, you know, or worse. So right, that's interest. That that seems like a big challenge initially to try to solve around. So, piggybacking off that, when you got started, that that customer that you mentioned that said that we're cool, well, we want to use...

...your stuff. How far along in the journey was that? was that less than a year? It sounds pretty rapid. Yeah, that was less than one year, and so big, big milestone for us with that first check. And then we work. We still kept it in Beta. We worked more closely within just to, you know, make sure that we did allow for every button to be pressed pretty quickly. That became our focus for sure, and this is kind of actually a theme of how we really suffering in general, and you are going to see some hints of this later this year, where we really like to have a close set of partners prior to making anything public, just to get some of that really in depth feedback and making sure that you know, we are, in fact, like I said, set solving a real problem for people, delivering value. And then after we kind of go through that refining have a larger public release for some of the lessons learned, etc. And then continue to iterate in the open with the community and, you know, all the diverse set of users that we have having the community right now. That makes sense because I think, you know, as you iterate through, building a product and idea doesn't mean it's a product. It just means it's an idea and so you can prove it out with some some opinions from people that are willing to pay for it or, you know, invested in with time. So, you know, we see open source projects. You see, you know, massive community involvement around things that are impactful to that community and usually that ends up turning into an enterprise offering at some point. So yeah, no, that's that's that's in true. That's quite fast. That's pretty impressive because, you know, you run into a customer who wants to give you money, you know you're a lesson. I mean that's that's quite a quite a hurdle to get through and it's really important too, and this this is true both when you're looking at your commercial offering and in your open source offering, that you don't let that one customer drive your product in a Vacuam right, you're not building it just for them, although of course you are building it for them, but with a lot of other people in mind, and so it's really important, especially in the early days. But I mean, I think this is universally true, to just keep your eye on what problem you are trying to solve, kind of even independently of that first customer, and making sure that you know you have a good quality gate for when to make decisions. So just because a customer requested feature doesn't mean it's a good idea to build the feature, for example. Right, absolutely. So as an organization, you know, you leading the you know the development practice around the product. What what are some non technical challenges you've run in over, you know, three and a half years. Usually this revolves around building a team and things like that, but do you have any lessons learned around that side of the business? I do, actually. Yeah, hiring is hard. That's I don't need to talk about that. I think everyone knows that. Yep, I think for us it's a lot about culture and making sure that we really thoughtfully considered our culture, even when we were a very tiny team, so that we could scale it, because there's this mysterious point that happens where all of a sudden you're bigger than you thought and maybe don't have a close relationship with every single person and the company anymore, and so it becomes harded and retroactively attempt to create a culture and, you know, set of values and standards, and so we really we would iterate on on culture, you know, values and standards, how we work documents like that, even when it didn't make sense because there are only maybe five people working on it. But that way, whenever we did hit that kind of inflection point, started to bring a lot more people in. We had a very thoughtful answer to just pretty much everything, and so we had very structured on boarding process from day one, where we send you through a set of trainings and, you know, you have ninety day plans and like, we did all this stuff that I don't think is typical at a company of our size when we were doing it, but it was a massive, massive value add for us and they think. Another part of this is making sure, especially at a startup, that you have a...

...culture. We're making mistakes and learning is valued. Actually when you make a mistake, that that's an opportunity to learn and I don't think it makes sense to have an empowerment without the ability to make mistakes and fail sometimes. And so you know you'll have developers, maybe on the more junior side, that are just petrified to do something, or least something to pride, because what if they miss something up then and you just have to remind them that, hey, we're all going to make mistakes. Here the catches that we don't want to make the same mistake three times in a row. We always want to be making new mistakes. That's actually really hard to get people to. Everyone will mid but to really do it in practice can be a little bit more scary, I think for some folks. We have to be very intentional. Right, so in order to enable your development team to live on the edge and maybe screw some stuff up, they've got to be able to do that in the way that it's not completely rule in the product. Right. So it gets down to like the you know, you talk about on boarding. You know we have a way to do on boarding so everybody knows what's expected and where they should do that and how they should act and who they should reach out to when they need something. I see that as one of the bigger challenges with customers, with their development teams. They're like, I can't set this thing on fire, even though I probably need to put this in a test environment and set it on fire just to see what will happen. So, you know, so they're just like making small, incremental improvements instead of going maybe this is trash and I need to rethink the way this looks. Yeah, and to be a little more concrete. One way that you can achieve this is the leadership team making sure that they are willing to admit when they're wrong, you know, internally. And so, as an example, we've changed our pricing model, you know, a couple of times over the years and will have, course, have a presentation justification for the pricing model, explain the reasoning why we definitely think it's the right fit, like very confident, etc. And then we learned that we were wrong and that's totally fine. And so then we make sure that everyone's on board and we give the the next follow up presentation, a year later, whenever it may be, explain what we learned, what mistakes were made and why we're changing the next one and just never being afraid of just revisiting every single decision and openly doing so. And then the more you do that, the more people start to realize like hey, we are all experimenting together and learning from each other, and that's totally okay, as long as we do it, you know, intentionally and thoughtfully along the way, right. Yeah, so if you're if you're showing by example a culture that's willing to learn, even with something that's maybe, from an engineering perspective, benign. Is Pricing, right, that's a sales thing, sure, Yep, but having engineering understand why you're making those decisions, because they don't. They probably don't care if it's five dollars a user or a five hundred dollars a user, as long as it does what it needs to do. But that, I think, that provides valuable insight into the business. Yeah, we made some assumptions and guess what, some of those assumptions didn't line up, and that's okay. Exactly. Another way that we kind of talked about this internally, as we use the word inertial thinking, which is just you start to justify things because of the way things are, like, Oh, well, that code exists and there's a hundred lines of it. Therefore we can't change it. It's really important to not ever do that and always ask, but is this code still relevant today? If you know, maybe it was the right decision, you're go to write it, but it might not be today. And if that means that we're going to delete all this code, that's totally fine. We shouldn't get hung up about that. If it's the right decision to make for the future right now, that that makes sense, but that I think that requires, you know, some trust within the organization. That a lot of trust. We consider and say this thing that we spent, you know, three months on last year doesn't help. We're calls anymore. Maybe we've evolved past this and that's that's fine exactly, but you know, that's probably...

...someone's baby or someone's sacred cow right. So, Yep, to they have to. You have to kind of get over that emotional attachment. And sorry just to like keep pushing on this point further, just mentioning this emotional attachment to things. That's also the way that we frame disagreements internally, is that disagreements or opportunities to learn. They're not opportunities to be right, and so a disagreement means to people have conflicting assumptions somewhere down the line and it's our job to find them, identify them, you know, figure out the right way forward or, sorry, I shouldn't say the right way forward, figure out a way forward that allows us to revisit that decision with no emotional baggage, because if it becomes an I'm right, you're wrong, argument, then regardless of the decision that's made, you know, if you do need to revisit it six months down the line, someone seemed like I told you so, and that doesn't help anyone when you're thinking like that. Were there any resources that help form some of this you know it call it like a organizational psychology that you guys are implementing and, you know, helping your team embrace. You know, was there a book or maybe a podcast or leader out there that you know, helped make this scinct? Maybe it's a collection of things. I'm interested in this because this is what I do, as I build teams and structure around that and how do we work and what do we do? That's what I've spent the last fifteen years doing. So it's it's really interesting because you have a very mature outlook on growth which is not common, and lots of organizations, big or small. Yeah, and I appreciate that. I think. I think there are some like, I'll say, intellectual seeds, and then at least one book that we do give people. So intellectually, I think comes from a few places. I mean Jeremiah and I actually are both so I have a PhD in math. He comes from risk and so very probabilistic thinkers, and I think that's one aspect of it. So that's not about being right, it's about preserving optionality and some probabilistic sense and then working through that. That's a little bit harder, I think, to get to certain folks because you know, there's all there's a lot there. Another one just for pure engineers is actually just principles of software design. So I actually look up a lot to sandy mets, who's a ruby programmer, and she has some really great books on on design that I encourage all the engineers to read. And there the velocity behind them is that there's always change happening and so your job is to solve an immediate need while preserving the ability to change in unknown ways in the future. And so engineer is really can get their hands on that and you know they've lived through a codebase for a year and know what that feels like. And then all you have to do is say and the same issue at the organizational level in the decision and processes we made. They're always changing. We should never optimize for a static state of the world because that doesn't exist. There's no equilibrium, especially at a high grows start up. And then, lastly, probably the most concrete answer is creativity. Inc Actually, he picks our book we give to every new employee, and in there are a lot of elements of this. So just the idea that every idea starts bad and you have to work to forge that idea and and you know, revisit things and throw things away when they're not working. Very cool. Love that. Yeah, I mean, you know, everybody's journey is different. You know, I've probably consumed forty books on business and building culture and a lot of the themes are the same, right, it's just how it's how it's presented or maybe some of the stories that you tell with it. So that's really interesting. You know how you guys have arrived to this is how we want to communicate to each other. Right and I think you probably read been Horrowitz is you are. You are what you do, I think, is the title. But I think the the important thing here is that we can talk all day about the intellectual side of it, but it's really important to have ways of demonstrating it.

And so just one way that we do this, once again on the engineering side, is we have a weekly hour, hour and a half long, open it's not really a meeting, that session called product office hours, where we just any idea, no matter how insane, is totally you know, open for discussion. The idea could be like we should pivot entirely. You could say anything you want and then we all just talk through it and there's no pressure to reach any conclusions. But it kind of gives us that place to continually have these discussions of how do we make decisions and think about our products so that everyone can start to get a better sense for what we mean. We talk about these things in the abstract. So it's a structured way to do audiation, basically exactly exactly. Sometimes we get features out of it and sometimes we just, you know, talk about fun cool technical challenges. Sure, yeah, that's awesome. So one of the things we always try to tackle on the podcast is the theme of speed, scale and savings. So that's a little sales e, I'll just go ahead and say it. But at the end of the day, when you're when you're building a product for customers, usually trying to solve for one or all those things. So maybe it's a two part question here. How do you think maybe you built your your application stack with that in mind, because you know you're probably not, you know, open sources one of those decisions, right, but you're probably leveraging other open source projects, I would imagine, to some degree. So maybe how you're doing that internally, and then how do you convey that to your customers in a way that resonates with them? And so just to be clear, you are you referring to speed, scale and savings that the product delivers, or do you mean speed, skill and savings internally when we're developing the probably both. Yeah, so I would say let's start internal. You know what some decisions that you made there that you know, maybe Aligne to some of those attributes? And then shifting to the customer focus side, you know what is maybe some of the value prop of you're offering to customers that they attached to. You know, what Gotcha might be speed, you know, for your customers, right workflows kind of important from a from a speed perspective. That's where it's hard. But yeah, internally, you know what what are decisions or inflection points within maybe how you're doing business with your development team? That aligned one of those three attributes. Yeah, so I think speed and scale or the too, that resonate most with me, and there's a few different dimensions to that internally. So first is we want to move quickly while gaining knowledge, and so that kind of goes back to I was referring to about releasing mvps to get quick feedback. Like we want that iteration cycle to be one where we're constantly gaining knowledge and, you know, writing down thoughts about about ways in which the product can improve, and so we do. And also responsiveness to especially to our open source community members. And so we have a really, really active slack community. Tons of questions a day and we try really hard to respond, you know, someone to respond within thirty minutes of every question being answered, and that responsiveness has gotten this a long way, created a lot of good will that we really are here to help people and so so speed. In that sense, that's both an internal and value add that we provide. On the support side, savings in terms of what the product offers is very largely about both development time and maintenance time. They get saved. So one of our product principles is you should be able to, you know, have a minimal set of clicks in the dashboard to quickly get to at least where you need to focus your attention when something is failing. And so that fast, fast debugability cycle is really important and I think that most of most of our customer like case studies and...

...things, focuses on that engineering time save a way, a way to think about this, especially when you think about Defensive Code. Defensive Infrastructure is especially in the data space. People will routinely say things like I spend ninety percent of my time writing what amounts to defensive code, whether it's data cleaning or try accepts, logging, etc. And so if prefect can do just the smallest amount. And so if you think about it in the in the data space, a lot of data folks will say something online that they spend ninety percent of their time writing what amounts to defensive code. So whether it's data, data quality, data cleaning, try accepts, logging, things like that and if prefect, can get that number down to eighty percent. So just a small amount. You know, seemingly of time savings. We've actually doubled an engineer's productivity because they went from ten percent to twenty percent of their time writing innovative code. And so the problem space is is a really powerful one to focus on. And you know we see that in boring out a lot in our case studies and our qbrs with customers. That time savings is just a huge part in operationalizing things to write. So the more efficient we can be about the way we work allows our other side of our brain that does innovative work to solve bigger problems instead of constantly putting out fires. Exactly exactly, and I think you know, the future is continue to focus on getting that negative engineering, defensive coding down and then eventually layer on top a lot of insight delivery about, Oh, you know, this task has been slowly taking longer and longer over time. You know, predictive analytics, things like that, Gosha. So we always like to wrap up with asking about some advice that you would give to someone who may be aspires to do what you're doing, or maybe they're in the middle of it right now and they need some encouragement. You know what's maybe a best practice, good piece of advice, something interesting along the way that you share with people commonly, that kind of thing. Yeah, I have a few different thoughts. So I mean there's the culture side. Think about your operation is sooner than you think you need to, etc. I kind of touched on that. I think maybe more interestingly is especially the founding team or the leadership team. I do have a guess advice for them, for anyone listening. So the first one is someone once told me the worst job to have it a start up is the job a CEO wants, and for Tech Startup specifically, that job tends to be owning the product. So something in product Lan and all that really means is that in the early days, when you're still small and having to make really large decisions, you know the founding team is going to have a very strong opinion about the direction of the product and it's actually important for them to be really involved in a lot of those dayto days for as long as it's feasible, so that you know, the direction of the company stays consistent, the vision stays consistent, etc. And then, of course, eventually you start to scale that out and that's that's totally fine. So just staying involved for as long as you can is my first piece of advice. And then on the flip side of that is, you know, I kind of just say this a lot, like don't optimize for Setx, say to the world, and so do not think of your role as a set of, you know, known responsibilities. I think it's your job at a high growth start up to just be as absolutely adaptable as possible so that you can unlock your team and, you know, really start to empower them to make innovative decisions, to make mistakes, things like that. And so I've seen people who get maybe nervous because they're feeling time pressure, but they also don't want to hire for it because it feels like something that becomes, you know, they they now are no longer responsible for it, and that's almost always a good thing, because there's so much to always do. There's just no way you're going to run out of things to do. If, if, you if,...

...and when you have to delegate. Yeah, absolutely, we've been passing around this, this phrase for the last five or six weeks, and it was how would you solve this problem if you didn't have a boss to go to? Oh, I like that, you know, like can you figure it out? And there's somebody smarter, way more famous that said that, but it's pretty clever, right, because you either you're either focused on solving problems or you're waiting all other people to solve your problems. And when you're in a Highgrod of software company, you know, if you're building a product, you got to solve problems creatively, often without a ton of mentorship, you know, just dry some things out and see what happens. Right, get guns when you can, and that goes right back to that empowerment is the ability to make mistakes and not, you know, fear the consequences. Yeah, absolutely, and you know, like we focus more on consulting. So for our customers we have to be creative and take some risks and well, you're doing things this way, how about we try this this? This would align with what we think of best practices. And your use case is strange, which usually is coding for poor, really poorly developed. So we're going to recommend doing things this way and see if that works. You know, and that's you know, consulting scary. Building a product is scary too, because you know you have people paying for it and if it doesn't work, Yep, it can get weird. So exactly. Well, Chris, this has been super enlightening. Appreciate your time and your your transparency and openness about, you know, your journey today. Very interested to see how you guys continue to rise in the future. Yeah, thanks again, Nick. This is really fun conversation. Thanks for having me. All Right, thanks, Chris. Have a good one. You two. Application modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux, cloud, container and Coupernetti's technologies. Thanks for listening to application modernization, a podcast for high growth software companies. Don't forget to subscribe to the show on your favorite podcast player so you never miss an episode, and if you use apple podcasts, do us a favor and leave a click rating by tapping the stars. Join US on the next episode to learn more about modernizing your infrastructure and applications for growth. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (30)