Sounder SIGN UP FOR FREE
Peer Check
Peer Check

Episode 3 · 8 months ago

#3 — Engineering in the Cloud w/David Heiny

ABOUT THIS EPISODE

The engineering world may have been slower than other industries to embrace cloud-based tools, but that gap is narrowing. More and more engineering teams are seeing the value of cloud-native solutions that integrate well with other tools.

In this episode, we speak with David Heiny, CEO at SimScale, about recent trends in engineering software, the future of simulation tools, and the challenges of making change within engineering organizations.

Join us as we discuss:

  • Strategies to successfully bring cloud tools into your organization
  • The future role of simulation across the product lifecycle
  • The tricky balance of conserving value vs. driving innovation

Welcome to peer check, a Colab podcast. This is a show for engineering leaders who want to challenge the sats quote for how design teams work together. You're about to hear a conversation about the ways the engineering world is changing and how top teams are carving a new path forward. Let's do it. Welcome to peer Jack. I'm your host, Adam Keating, and on this episode we're talking about strategies that you can imply to actually bring modern technology and cloud tools to your organization. I guess today is David Heni, the CO founder and CEO Sim scale. Sim scale and powers engineers to innovate faster by making engineering simulation truly accessible at scale. David's been building simulation software for the last decade. has a whole bunch of thoughts about where's applause across the entire industry as someone that I've looked up to for the last couple of years, since now we him and I'm really excited to having today. plishould be here, Adam, David, before we get in. So like our audience is listening thinking about, you know, what's really important to them, how they can get ahead as an engineering group. You folks build a pretty awesome tool that helps a lot of teams cross the world. What is Sim scale and where people using it today? And we said our deadline already perfectly. Or since skills, a cloud native civilation platform that empowers engineers to innovate faster but be consimilation more accessible. It's a you know, to not just repeat what you just said already. I'll try to unpack this a bit. We think a lot about accessibility. We believe that by making some lation accessible to the point that you can use it earlier, broader and design processes more intensely, and also in manufactoring, in operations, use cases, there's a lot of innovation, a lot of customer value. Share hold the value to be unlocked. So, since kill we take a lot of pride in the methods we've developed, in the American methods were employing, but we're not about, you know, this smashing piece or dissolver piece. We're really about making some lation truly accessible, and it starts with and to that end, we've built a cloud native platform. You know, serio software, several hardwarefoot print. For the people that aren't familiar with seem skill, you go to s scalecom create an account and within a minute you can, you know, you upload your cat model, defined Asimulation, set up, you know, you know under way and run some relations. Yeah, that's what we're about. How did you even get the starting seem scale? Because I obviously I've I've lived in world where I ran a lot of simulations, and I think about just even like the complexity of the file and like literally, we'll just share the file. I have filed locked up on external hard drive somewhere that I can remember the password for, but I couldn't send them any other way because back in two thousand and fourteen there wasn't good ways to share things. How did you even get the starting seem scale? What drove you started? Yeah, I think had'm honestly, it's not too different than from your experience. We've been I mean we're fat founders. We've got in touch with scientific computing software engineering in doing Grad school ten years ago and and for us, you know, being sort of cloud native, digital native, sort of the cloud was something that, you know, we use a lot of cloud software already, and so for us it was interesting to see that the while in, you know,...

...we used academic codes, but then looking into the industry, clouded option was so surprisingly low and we looked at why, and so more and more we saw like there isn't any good reason other than nobody has done it yet. And so that's was sort of the spark for, you know, let's let's try to see if we can pull this off. We're seeing applications today like where people using clouds simulation the most seems gale, and other just cloud in general. I mean our point of views biased, but our strategy was very much sort of let's let's look for applications where we believe the cloud can create the most value the quickest. And so for us we started in CFD, flute an Amics, because, you know, it's very compute, intense. It's something that is not adopted because of that reason, is not an adopted to the point how structural analysis is today already. And so we started in CFD. We have a lot of customers today in architecture, in electronic schooling and rotating equipment or so automotive etc. And and we used our CVD development to establish the initial, I guess, components, the initial sort of basis for delivering a an end to end engineering as simulation workflow completely in a browser and now that we've completed this, we are actively expanding and actively pushing into additional physics. Structural analysis as always been part of our offering and it's going to see a lot of love in two thousand and twenty two. But there's also a new physics on the horizon which is not yet ready to be shared, Adam, but we'll share more on that shorter. That's awesome. Is there a sweet badly, I'm just generally interesting. Let mean, I actually could have used this when I was going back through university because the show we had as a lightning yeah, we should have. I should have. It was all real. Know you were at the time. But is there a sweet spot for semsgeller? You guys plan alongside of existing simulation tools, like how does it fit in small and big orgs? Because I think that'll lead into how we talked about how a team, a great Christian and also here this is, was very much under sort of evolved. Initially it was clear to put off all the components you need for an end to end engineering simulation work on the cloud. You know, cat ioh cat prep, Mash generation, saw cost processing, data management. Yet he added to pull all of this off. We knew would take years to get this, to get this right, and so we look for who would be the first organizations to adopt this, and this was primarily organizations with simple design processes. Of course the need for simulation, but no, you know, no very complicated PLM landscape, you said I want to do. You know, we had enough. I'll platter without that complexity. And so we focus, and that's why the initial organizations adopting SIM skill were primarily a smaller medium sized organizations often have the first simulation tool either in the department or within the within the organization. But over time, as our product matured or technology matured, larger and larger organizations adopted it, and so today, the we see we still on board a...

...lot of same organizations, for sure, and deer, to your point, there were oftentimes the only assimilation tool that is used for multiple physics within larger organizations, and you're right, Adam. That's something we're probably going to talk more about in a second. We see oftentimes some skill being faced in augmenting existing some nation capabilities, already an existing see a software and hardware stack which we also sort of I don't want to. I guess we're going to talk about this in a second, but which we think is the right way of adopting solutions such as ours, and that's awesome. I'm curious off the Hob like you folks can soft for your website. It's really quick to set up. Do you see the difference in behavior between Sumes and with the large enterprises, like, are the large enterprises still getting in there? Starting on your free account and going we're like, what's the difference between the two in terms of how they initially find, know, the love for same scale? So the we think they the there's a whole sort of in the entire software industry right there's this whole notion of product like growth of end user adoption and user driven procurement of software, and we think this is in engineering software. Things are a bit more complicated in than this, but but generally we see this happening. So we do. We do believed at assimilation tool should be, you know, easy to test, easy to try, easy to you know, learn. You should be able to quickly experiment with it and just and just prove out its value before you're adopting it a broader and as such, we're seeing sort of this end user adoption definitely independent of the organizational size. But of course as a rollout or a deployment of sem skill gets broader, of course then there's a big difference. And while in a smaller organization where both procurement processes PLM landscape, he said it's fairly simple. You see, it goes simple, but in large organizations I don't need to tell them, yeah, it is. It is great, though, you're able to offer that slice, because one of the things that we see all the time is the power of a strong business case and in most cases it's really hard to use an Roilia. Traditional Roy companies are looking for like they need to be able to actually feel it. It's like we're about to buy a piece software COLLAB FOR OUR FPS and security questionnaires. MMM, it's very hard to put an actual dollar number. What the value is it that outside of we know it's going to make us more effective a movie through our sales process and that was worth it for us, but there's no way to say it's me four X, like we can make an estimate but it's going to be wrong. So being able to actually see that you can run a simulation in you know, get up and running the same hour and actually get something going. That's like it's a very powerful thing for those people. Before we get into just like some of the things that people can actually do, I'm curious in the next like twelve and twenty four months, what do you think the role of simulation is for engineering leaders and challenging status? Well, especially now there's virtual...

...world, people are trying to not build as many prototypes. Why do you see the role being in the next year or two? Adam, and it gets critical how much time we have, because that's a question where I might get started to start rambling here, but I'll try to because twelve to twenty four months, okay, I'll start broad and then we'll iron in on the next two years. And we think today, at least in most organizations, simulation is a point solution that is primarily used in the latest stages of a design process. So when you have extremely mature design then it justifies bringing in the resource as hardware software, people that can effectively use, you know, traditional simulation tools. And this is where, you know, a great market as emerged and great software's been built today and you know it's a fantastic use of simulation, no doubt about it. But what we believe will happen is that as simulation becomes more accessible, right as the the the economical barriers fall, technical barriers fall. We haven't talked about Sim skill is not just accessible by a web browser graphically, but also programmatically. That API, as it becomes automatically programmatically accessible, we believe it's not going to just play a role in the late stage of a design process but also, you know, starting with earlier, okay, early stage. You know, design engineers will use it to quickly a test concept. That's also, you know, something more and more organizations are already adopting. But beyond that, we're seeing exciting developments around more automatic design, spased explorations where, you know, you take the human out of the loop, you know, being shape optimization, even now, with the convergence of ai and machine learning methods, where you're exploring the design space in ways where the previous previously not possible. And but and then even coupling it with one D and systems modeling tools. And that is something where we see where we think a lot of simulation will be will be used to drive, you know, ultimately design better products. Faster. But all of this is still on the design side, so it's still in support of designing products. Equally, on the other side of the product life cycle, when it comes from your factor and specifically operations of products, we're seeing more and more, you know, not just innovation use cases but use cases where, IUT digital twins, predictive maintains these use cases where they're actually being deployed in production and also they are it's use cases where you don't simulate the individual product design but you actually simulate each product instance, and that's also something where where the resonates very much. Would how we think simulation should be used, not just as a point solution but really as a as a horizontal layer in the IT stack of an engineering organization and supporting the product life cyclement broader. Now at am whether or not that's a twenty four months timeline. I just...

...spline or not. You know, like don't. Don't cite me on that one. But but that's at least sort of the bigger picture where we think some nation is going well. I was actually going to ask you because you know we hear a lot of it. Model my enterprise and Pete teams moving towards a true systems model of what they're doing. It's extremely difficult, but I think backs when of the university, the hardest course I think I did was modeling the naming systems. I think it probably was, because it's just so far reaching you'd understand every other part of engineering. Physics systems is just a big monster, and I was actually curious if that was your perspective too, because it sounds it sounds like what you're saying is that you see this becoming not just something someone logs into a browser to throw cab model into at the end or, you know, a simulation model into and run an export result. This is something that's like the wheels are churning and giving you insights throughout the whole processes to actually feedback in you know, what should your design look like? What what variation or what configuration actually works best? That's going to be like really, really powerful. Couldn't agree more. And am I said, don't get me started. But D that's also where we're, I think, trying to draw the lines. I'm trying to commit to what we are and what we are not. Right the reason, the reason behind the API is that is why we think the EPI and programmatic accessibility seamless. programatic accessibility is so important. Is that since you let the chord as simulation right and will add methods and will add physics and it's going to be real time and all of that good stuff. But you know, like the systems model or you know the system of record, if you design data or you know whatever other like. We think there's an unbundling happening of different tools that's going to interact with each other in a in smarter and smarter ways. And as such, yes, we try to stay true to what we're about and that's, you know, making some nation accessible at any scale and for sure and use cases where we right now might not even be thinking about yet. I'll try to stop. Do I want to take that then nugget. There just unbundling of the tooling like right now. I think we've lived through the last two decades, in the engineering space in particular, you know, a handful of companies delivering most of the software across every single possible use case, problem in need, and we're starting to see that change right you're starting to see a little companies popping up and grabbing a slice and integrating really well. I think about evenly on shape. On shape took a very different approach to how they built their API, very strategically built and so that they could plug in anything really easily move from there. Talk to me a little bit about, like just go a little bit deeper on the API portion, because it's something that I think a lot of people don't fully understand the power of and the importance of, like being really good at one thing and playing nice with others, because all other injuries are done. It like the software will. We live in building colab everything is plunged together. You wouldn't know. You wouldn't you wouldn't know that all different tools right in the hardware world, anew of your Cadsu when your PLM. Most of them can't even properly play well plm the PLM, let alone to another tool. What's the importance of the API? What can people do to actually think about, you know, accepting that or, you know, investigating that as an organization today? And so how I typically explained it is that the or easy way to explain it is that...

...simulation in itself and like nobody wakes up in the morning. Maybe simulation people. I personally. But everbody wakes up in the morning he says, Oh my God, today I'm going to run a bunch of simulations. Right, it's not like no folks that seems get get excited about that. And maybe at the simulation software is but not everyone does. It's ultimately in support of designing better products, faster operating a good product, creating more value of the end user, the customer of a product, and and so as such, the more automatic, the more you know, the less human interaction you have in there, the better. And can share a few examples later on. But we think that today most of the simulation use case is still involved an engineer and you know, sitting in front of the computer applying boundary conditions into interpredding, post possessing results. And I think in the future, as as hopefully you know, the industry gets better at capturing requirements, building more sophisticated systems level models that are integrate nicer with the rest of the engineering software stack. We think like more and more from you know, requirements all the way to the MANU factor product. One more automation will happen there and and for that that's why we think programmatic accessibility is just almost like it's a given right. And and today also, like the core of this idea is new. It's like every every similation system out there has a you know, has some sort of scripting. But practically what it means to say us to start this up, to even have the hardware it, have the license as ready, to practically access sibilation programmatically, you need a methods group, right, and largest organizations have it, but but even them, right then it's siloed. And these this group has access to the scripts and can use them, but what about it outside? And so so that's the the thought, Candpi. Now, I mean if you think about like the Zappiers of the world, who are like literally making this like it just automatically, I think that's like the level, maybe not quite that level, we need right now. But if you think about just the conversations we've had before about PLM integration, you know some of those can cause can take six, twelve months for really good companies that know what they're doing, with teams and resources behind it and a full focus to do really well. And most these seems, don't have that. They don't have it budget, they don't have an IT team sitting alongside. They're trying to get into something get done quickly, and that's why I like I think what on shape did is, you know, an absolute beautiful first step in the cat world and seeing companies like yourselves do that. And then I think it's going to be a in a requirement, to be honest, of new tools entering the market that they actually have an easy way to plug and play nicely with the everything else, because engineers, their teams are asking for it. We hear it all the time now. COLLAB does it? Doesn't agree with Jia? Doesn't your teams that we are hearing these questions all the time? That didn't exist three years ago. We start a Collup, I never heard that question and today it's like a it's a standard every single conversation I'm in to chime in. I think the and I think it's...

...clear why that is so right, because there's a lot of like a different complexity sitting in hotware engineering. There's a lot of the moment you have a menu factor product somewhere and you operate this. It's just like that de level of complexity and it brings us just different than it is and software for sure, and managing the life cycle of such a products is more complicated in it software. But I'm completely with you on the idea of we oftentimes play with an all analogies and software engineering dead at hotware engineering. The future will look closer and software engineering than it does today. For sure it's going to, because the products are becoming more software and electrical man you look at even just automotive right like if you look at the new Tesla's and zooks and all these kings are popping up, if you looked at their engineering team breakdown, there's a lot of software and lostical folks in that group in comparison to, you know, fifteen years ago in traditional automotive. And all the other companies are all going that way. They look at the Super Bowl weeks ago. What were the add the ads were all evs. Every single company ran ev adds the whole way through it and it's just a massive shift. I'm curious. So, like obviously the role simulations clear here. I think thinking about, you know, programmatic access. How you actually a strategy? That's important. I think that's interesting, though for me is I think a lot of people probably agree with that, but they have a hard time making a practical. I always say to people like you know, if you're going to make a change, having a solution that's like three to five times better might not be enough to to make someone movement the status quo. What are you seeing the best leaders do to actually make a change happen when it comes to implemented simulation, to all implementing something else that, you know, maybe not the normal? This the normal status code today. How are you seeing them actually get over that Hump and make it happen? On the note before, I wasn't sure if it's a kid to share that I haven't seen the Super Bowl ads Adam, but I'll make a note that I'll google that later. Promise there's a lot of good, a lot of good. I'll check this out. And on that question, let me start off by saying the I think it's completely it's almost that if the nature of the best that the the engineer organizations were serving, the customers were serving. They've created so much value with the products they've been designing. When you're factoring and shipping or you know the AC industry, those buildings and civil engineering structures they created. I've created so much value that needs to be conserved and so and so that's why I think it's just a nature of the bees that they have so much value to be conserved that naturally, the systems and the processes and work close they have set up. They are there to conserve all of this value, and that's why I think it's it's almost sometimes oftentimes say here, is that it? That? That's natural. Right, we shouldn't complain about this. They there's a lot of value to be conserved. And so, as such, now, keeping innovating and seat of reinventing yourself in such an environment as hard, right, and so that's why I admire the engine leaders that strike the right balance between...

...acknowledging that there's a lot of value our organization has created it needs to be conserved, while also acknowledging that if you're if you're not, you know, innovating the tools, processes people on a daily basis, you're sort of you know, you might be not on top of your field in a couple of years, right. And so striking this balance is hard and so, and as such, I admire the engineering leaders that get this balance right now, to what you know, good things we're seeing, as I guess, where we see successful change happening is when you not just think about the tool. It's often times we as vendors, you you typically you know, your tool great, amazing, but there's more than just the tool to make a successful change. This like framework, we fronds, uses, you know, technology, process and people, and so it's not just sufficient to have the right technology. It's the process that this technology is used in and you know, you check in if it's use and how it's used, instead of make not just to it, how you roll it out, how you change people, and then the people and how you bring them on board and when. Example I would give is one of our customers is fountain, Thomas Sady and a civil engineering firm, thousands of engineers and they have been there. We've seen a fantastic example of how they've adopted a simulation and how they made simulation more accessible within new organization in a very effective way. And it started off by initially the CFD engineers using sim skill and so adopting it, calibrating it, you know, and getting the confidence in the conviction that this is a tool that can create value, but in also acknowledging that they came to the conclusion that in order for their architects and more stakeholders and users within their organization to use simulation. They need a different process and so they ended up saying, going back to the API, they ended up saying they want to have those simulations that these people use run implicitly. As as such, they built an automation of effectively building a cat plug in for their cat tool they've been using. And so while the CFD and simulation engineers use SIM scale directly, they developed a small plug in, a small tool putting putting it into their d cat system where there the other users within the organization can run simulations basically implicitly. They don't need to know about some Scaley, don't need to know about doing intecracies, they can just run it, I'm automatically within the CAT system. And then, you know, gradual rollout, bringing people on board, and so as such, you know, not just looking at the tool but also thinking about the processes and how you bring on on board people is something that we've seen is almost like probably not not sufficient for successful change, but definitely required for a successful change. That's actually interesting. Examples a lot of what I think we'll see people think about. You know, the actual people...

...and process even ahead of the technology, sort of set of vision. You know, you get to look with what you have today. I'm curious in that case, like when they dove deeper, they prove I cfd group and I said, okay, let's move on to getting the rest of the team involved. How did they actually get justification that it was worth sinking some of their time into building that plug in? Like that's where I think a lot of teams get stuck, is like how do I justify it's worth it resources to actually do something about that, because it's not easy. How did they build that case? Like how? What did that process look like? Convinced than that, hey, this is worth doing it? Yeah, I guess I would need to invite them to the to the podcast, to talk to hit from the directly from the source, but I think I guess I can say as much dead given the the level of knowledge about our technology and a level of knowledge about our team and how we operate and what seem skilled can and what it can't do right, I think there's no unknowns anymore and so all of that risk is basically gone, right, and so I can only imagine it as an organization that it can has adopted and has built the conviction in a tool, in a technology such as such as this din, you have all the information and you need to build your own case. So in this case we weren't. We weren't involved in debt and building the business case. That's part as powerful when they can actually go build it on the round. Like. I think that's something that most or struggle with because is not clear right. It's not like you're comparing to cat tools and when you're looking at the license cost and you can very quickly say, okay, we'll save x Amout of money by moving to this or you know, it's not such a simple thing because it is much more of a philosophical change that is going to have a much bigger impact long term. It just is a way folks work in terms of like things. It is approved. Are you folks seeing much pushback on the cloud and, if so, how our teams overcoming that, especially in the bigger organizations? Do we see perspective? So I think it's a topic. You know, ever since skill was around, people have asked us and this was it's funny because but the interesting thing is that it is much bigger topic for you know here. It seems skill. It's not. It's not a huge topic. Versus in the industry and broader. It's discussed a lot, because I think it's fairly simple. If an organization today isn't ready, isn't committed, isn't you know, doesn't have a point of view that the cloud will be an important part of the future software stack, it's not something we going to change a sim skill. I think that's a that's a process. This organization needs to change. We can, you know, we can, of course, you know, evangelize and sort of showed that it works and of course we can be part of that, but I think it's just a journey that an organization goes through and depending on the industry, depending on the leadership and, you know, vision and culture of that organization, I think these are factors that are bigger than what we seems all.

You know, any other vendor can do so to that point, the there's industries, there's entire industries or also required certifications, where I think the cloud today isn't you know, isn't good thing to grafter, because it's more like yeah, your risk weight, the restrictions and that industry might be way too high. For a cloud solution to be dopted. Then there's others where this actually already today works. And so the the industry is and the organizations that have already made the decision, and no already that the cloud is important for them and they can clearly see the benefit add a value of, you know, accelerated collaboration, faster innovation, you know, you break down silos, lower, lower CAPEX is set and they've made their decision that fundamentally they want to do this. And this portion of organizations in our industry is already by far big enough, you know, for Sims cool to grow and prosper, and it's growing like crazy, like it's constantly evolving. I think covid accelerated a lot, but just over the last four years of US talking to Orgs, it's gone. We've actually started talking to people who tells they won't use colab unless it's about we're getting the opposite, because it's part of their philosophy. Right, you just said a moment ago about people process tech. I'd almost argue like the part you said after that, the visions, like the fourth part. The vision like comes back to your culture, comes back to what you want to be isn't work. And you look at like the shift that's happening now, and I agree with you. Someone is like anticloud to the fullest at the top down. Very hard to change that mindset. Well, it's happening now is their peers are all are all making that shift. So I think you're right. I think it's but education, it's but awareness, it's about, you know, helping build that case because over time everyone's going there. Like it's it's inevitable that everyone will be there. It may be a different capacities just based on industry and requirements in rice, but the every everything is shifting. Sentence off and then say, as you know, we're in the right set of history with Sass and, you know, cloud native. Now, since we're recording this, let's check back in ten years. So I don't this recording whether or not that was the case. But to your point, I couldn't agree more that. I remember Nathan's Conferences we went to, you know, like five six years ago, where it was definitely something much more exotic to be cloud native and browsing. Today, I think there's more and more tools and there's more and more acceptance. Yeah, so I think we're seeing this trend in front of our eyes right now. Yeah, like it's to the point now we take it for granted, almost like the same way we can take video calls for granted. Even two years ago you couldn't. You couldn't get most engineering teams on video call, like most did not really use video calling. Like I used to fly all over the place because it was just easier to do demos in person than it was to get on a call. And now it's fifteen seconds, slip open, you're winding down. Is Better for everybody, half for the most part. So I'm curious to kind of like just take back to that thought. We talked a little bit about, you know, simulation impacts going to have, where that can go, how teams can think about, you know,...

...actually make that change way people process technology perspective. As the human early, as the leader there, what do you think makes like you're describe the person who is like leading the change in the ors you work with that are most successful. What does that person look like? What are the characteristics? What are they embracing, like what kind of culturally fostering? Just walk US throughout that that champion looks like. After the teams that are working the best. Yeah, I think the one, the one characteristic, or I'm not sure if it's a characteristic, but I think this one approach that I would go back to is the one I alluded earlier to. We're like this deep conviction that the you know how we did, or an engineer lead at has this deep conviction that in you know, five years, ten years, you know, you name it. The conviction that the design process, engineine process, the product life side within our organization has massively changed or has fundamentally been, you know, upgraded or changed, while at the same time acknowledging that there's a lot of investment into existing infrastructure, is, existing processes that are worth conserving. And so someone that that that has this big picture in mind instead of is is is convinced that that the that the change is inevitable, that in that we did, you must be at the forefront of this, while at the same time balancing that you want to conserve the value organization does today and then, you know, rigorously executing against us, you know, taking step by step, making sure you take incremental steps, you you manage downside, and we've seen it read that is a famous engineering softar roll outs that didn't work and and D and guarding against a while gradually pushing for leveling up your organization is I think it's the one thing that comes to mind when you when we depicted this engineer leader. I guess, yeah, I think you can almost summarize as a visionary but rational, like very rational and pragmatic, and like their approach. We see the same thing. Because you don't know where you're going, you're sure fire end up in the wrong spots, the same that you were driving your car right you didn't know you're going. Your end up somewhere may not be the right spot, but if you're, you know, just down the Wei's taking little steps, you also end up the wrong spots as a combination of like having a target and then taking the baby steps so that you don't get in these four year software roll as to cost tens of millions of dollars and everyone's like, well, why do we even do this in the first place? I think that's like ultimate shift. But I think everyone's starting to shift that behavior, like it's consumer behaviors changed, right the way you buy software in your personal life, like just the way we like live on our phones with all the APPs we have there now versus ten years ago. Everyone's come to no, like try it, see if it works. Double Down, try it, see if it works, double down. Like this pretty much become like, you know, the way you will behave. Just obviously the engineering world there's a lot more existing infrastructure. If they need to be thought I agreed that. I think this, this trend, is bigger than engineering. SOFTA what means almost trend. I think this this natural development from no, I need to be careful because this was before my time. It's a software founder, but do I've been told that, you know, back in the days, you had one major software purchasing decision. You, I don't know, in a decade or in two decades,...

...because you had installed this huge system on which the soft terray and its he get one major of en a decision. And that was, you know, for ten, fifteen years. And so today, right as we and BEB BEB says, it's almost normal that everyone has some sort of self adoption, that some gradual sort of land and expand at type of motion. And I think it's it's it informs how we, as Softwa vendors, I think, approach how we build software and the way it can be consumed and tested, but I think it's also for the right way for the engineering lead to too. Yeah, gradually adopted, gradually test, prove that value of a new tool before you, you know, go go to the next stepdoin the thing I love about it, outside of like it the risks what they're doing, is that every single time I've seen it happen, where they started in terms of what they thought the tool would do and what they actually wanted to do and where they end up are always slightly different. They learned something by doing the first part that says, oh, I don't care so much about that anymore, but hey, I want to double down your example, on integration for the rest of our architecture team, like that stuff that you did. You can't tell when you're looking at a website. You can't tell when you hypothesize a problems until you get in there you see the behavioral switch like we nine times out of ten that's been true at Colab. I think it's true with any tool we've even implemented ourselves. Like I look at sales force. We've met to gred sales force with like all of our tooling, and the thing that I actually love the most is and every thought about is like really simple. Click a message, send the sales force ends up on the deal. So the most simple integration ever. I never would have ever asked for it, but it's probably the highest guy thing for my workflow because I live in slack and I think that's so true with engineering tooling. To you don't know it till you've started and it's hard to pitch you know, big pipe dreams before you get going. So taking the baby step, take goings, what were them? And to Refund Dad, and also the ability to just hash out quick prototypes. I think requires the ability to to just have soft it be diffused within an organization and not haven't been constrained by hotw limitations, by you know, logins and whatnot and installations and it requirements. And so the moment you said, of you know, people have access to the tool landscape, you're going to see your productypes, you're going to see innovation accelerate and yeah, so couldn't be more. That's awesome. Yeah, and David, I like I'm just thinking about we talked about, you know a few minutes ago, about how what the role simulation is going to play in all this. I think that's going to open up a lot of those feedback loops that people aren't even thinking about now, which is why, this is why I was excited Chatwig's I know I'm seeing it now. We're hearing all people ask about systems engineering, what the future is going to look like, and it is going to be. You know, it's programmatic like you don't even know it until you get the insight. I think about just like the parallel to software world and some of the tools we use. It's already happening there. You already behave that way and it's going to be powerful way for engineers to move forward make decisions. I want to thank you so much for being here today, thank you for sharing your insights and really excited to follow...

...you folks on next next couple years. I'll hold I won't hold you to twenty four months. I do recommend you check o Suer Bowl adds and I'm sure we'll see lots cool things come from you in the same scale. Team, thanks for housing awesome. You've been listening to pure check, a Colab podcast. Keep connected with us by subscribing to the show in your favorite podcast player and please leave a rating on the show that helps us keep delivering conversations about how the engineering world is changing and how you can challenge the Status Quell until next time.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (18)