Dr. Ralf Huuck, Logilica

Thank you for tuning in to today’s TL;DR episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but look at it through the lens of business and engineering leadership. Joining me today we have Ralf Huuck, founder and CEO of Logilica and an adjunct professor at UNSW Australia. Ralf shared a pretty sophisticated view of what the API lifecycle velocity actually means when it comes to not just the technical but also the business and politics of how software is being delivered within the enterprise. Let’s just start with the basics: who are you and what do you do?

Yeah, thanks for having me, Kin, great to be here. I’m Ralf Huuck, I’m the founder and CEO of Logilica, and we’re a data analytics and data intelligence company for engineering leaders. Basically we’re a bit like the second brain for VP of engineering, keeping track of your delivery and production pipelines, grabbing all that data, running data analytics on top of it, and giving you the top-level radar view about all the activities that’s going on. And APIs are our bread and butter on a daily basis, so it’s great to be here.

Thank you for joining me. The view that I’m spending a lot of time in is what, I guess I know Gartner uses the phrase platform ops, but there’s this Venn diagram of a lot of ops. So DevOps, GitOps, platform ops, SecOps, and so I’m living in this spectrum right now. When I first came across what you all are offering, I’m like, oh yeah, this is cut from the same cloth of the world I’m trying to understand. So let’s start at the highest levels: what’s the value to business and engineering leadership when it comes to what you all are building and that view of the landscape you have?

Yeah, for us it’s really about creating clarity around the engineering process, having a little bit of governance on top of this, but really being able to deliver product faster. So basically from the inception, from the planning state, let’s say in your Jira tool, Monday, whatever you’re using, Shortcut, down to the development pipeline, to release and production, how can you make that process as smooth and as quick and as accelerated as possible? And obviously, as you know, there’s a lot of bottlenecks in the software development lifecycle, from people being overloaded, from your build server running too slow, from tickets being stuck somewhere, and all of these signals is what we pick up in the software lifecycle through APIs, and then give leadership a top level view around this. How do we able to minimize the friction, keep everyone happy, and being quicker to market, and obviously in that sense serving our customers better, and being able to react to customer input and feedback much quicker than we would be able to normally do? That’s really what we’re looking after.

Now for developers on the ground floor, down in the weeds of operations, what’s the benefit?

So first thing, you don’t have to do manual reporting anymore, so that’s one of the important things. If your boss is asking, hey, what’s the status of my tickets, or how do we do, what did we do last week, or are we stuck somewhere, what do we need to focus on, the last thing you want is to compile this, talk to three of your colleagues and put it in an Excel sheet, and somebody puts it into the Excel sheet, and then at the end of the month they see, oh, actually the build times are like three times as long, maybe we should address this. So we want to gather that information automatically, cut the overhead and burden for development. But then in turn also give developers a good argument, look, here we can do it much more of a data-driven approach. Things take too long, yes, you kind of say we need to get through more tickets, but the build server runs half a day, so we can only do two builds a day, and we really can’t do the whole test development cycle, we have so many tickets and we only have three people, we can’t do five tickets a day, that’s just not realistic. So you get a lot of evidence and a lot of data that you can use to communicate into both directions.

And then obviously the more you move to a more open team culture, the much more you can bring all the sides together, and you being able to really see things that you normally don’t see. It’s not that you don’t have that information, but it’s typically deep down in some silos, and if you’re a developer, and you probably know this as well, there are certain parts you care about, other parts you really don’t care about because it’s not your job, but that might as well impact your job. So if that visibility is not there, you have to suffer the consequences of somebody else not seeing that context information, and bringing that together, I think, is a real benefit to the developers, once again saying, hey, we are overloaded and this is the reason why things are going too slow, instead of the blaming, finger pointing, complaining in both directions. So we see that creates much better understanding, better team culture, and happier people is happier delivery, that’s at least the hardest part.

So this is a very observable, transparent, collaborative process, it’s not a big brother looking down monitoring solution for leadership?

No, we stay away from this. I know there are solutions out there that measure developer performance, that’s not really what we do. What we look into, we don’t care whether you produce 20 lines of code or 200 lines of code, because we don’t think that’s really comparable. It’s more about the process. Do we follow process, do we do code reviews, is there something where things are stuck and is it something that needs attention? And that attention could be, let’s say, on a daily standup, we have PRs that have been in review for three days, so maybe just somebody forgot about this. So it’s information that nobody needs to know other than the development team, so you can resolve that proactively before it bubbles up later. And it’s really not about measuring people’s performance, because, as you and I know, different developers with different tasks, it’s not something you want to do or can really do. It’s more about the processes, is the pipeline smooth, do we deliver smoothly, all these things. Do we work on the right things? If you suddenly have half of the team working on bug fixing, the question is why is that, so maybe we have too much technical debt that we can address, and so on and so forth. So these are the things we’re much more concerned about, rather than individual performance, because in our view software development is a team sport, it’s about getting good teams together and getting basically the telematics to optimize your processes around this. And sometimes I use the comparison to Formula One, which is at least quite popular in this part of the world, you have these race cars with all the telematics, and it’s really about how do you optimize your race, rather than how do you optimize and blame the driver for not doing the right thing.

So for me, I’m focused on the API lifecycle, software development lifecycle with the API lifecycle kind of overlaid on it, delivering microservices, public APIs. But velocity means different things to different teams, in different APIs. So how does this layer help me understand truly what is velocity, what is meaningful or purposeful velocity?

Yeah, I think that really depends who you’re talking to, and these are the different layers, as you said. On an individual developer level, your velocity might be how long does it take you to work through a pull request from opening it, coding, reviewing it, merging it back into the main branch, and we can come to DORA metrics in a moment, but ideally these cycles are like in a 24, 48 hour time frame. And then maybe you have feature tickets, how long does a feature ticket take, well typically it should be happening within a sprint, and your sprint might be two weeks. So you already see you’ve got different levels of velocity. And then on top of this you have your infrastructure, so how many releases or how many builds do you have per day, how many releases do you have per day, and how successful are the releases? And that’s where we can come to the DORA metrics. The different velocities speak to different levels of the people in the organization, but it all needs to fit together in order to deliver smoothly, because if any of those velocities is really stuck, then you probably have a problem.

So is this an additional layer, is this part of my, if I’m an API product manager, is this part of my feedback loop that I should be building into everything that I’ve taken into account as I’m iterating and moving forward my products? Maybe tell me a bit more about what your API product manager is doing in their day job.

I’m focused on business outcomes and business objectives, and I’m hopefully aligned with my consumers and I have a feedback loop in place with them. But that’s very dependent on the velocity of my team, the quality, the reliability of the build, because the APIs could be building, but I could be issuing a lot of patches, there could be other quality issues in there. So as a product manager, I’m worried about my consumer getting what they want and when they need it, and being agile and flexible that way.

Yes, so in a way this is your internal feedback loop. From our point of view, it’s everything from inception to shipping it out of the door, and then it’s over to the customer side, and then you have the typical log monitoring and external feedback and consumer feedback, sentiments and so on. But how do you create that internal feedback loop, the internal steps that are quite often, engineering is sort of an art form and it’s a black box, and you don’t really see what’s going on. If you can bring clarity to that, you can streamline your processes much better, organize the team, see where you need to allocate, and basically your internal spend you can allocate to the right problems and make sure that you have the delivery as efficiently as possible.

So how, at this layer, how much of the friction that you most commonly see is people or technology issues?

Yeah, I think that goes hand in hand. If you have technology issues, you’re going to have people issues, because it starts off with your tooling, and people don’t enjoy their tooling, they’re going to be frustrated and you have people issues. Obviously it’s a bit of a team culture and an organizational culture thing as well, and we can’t discount that. If you have very much a command and control organization where people don’t work together and just get dictated what they have to do, better data doesn’t necessarily help you, because probably somebody in the organization has got some vested interest that that data doesn’t get shared around, it is not visible, because it takes away some of the command and control power. But I think especially in more modern organizations, and especially working in a hybrid world, working remotely, if you don’t get that information together, people will feel very isolated, they don’t have a view what’s going on, and it really becomes difficult both from an engineering but also from a management side.

We’ve been working mostly remotely in the last two and a half years, and it’s difficult to always stay on top of all the different activities going on when you’re not in the same room. Normally you don’t even need to have a standup or a meeting, you see what’s going on, what’s happening at the desk behind you, you always get that sense around the right signals, is somebody frustrated, do things not work, or is there a sense of panic. If you just do this remotely via Slack or other tools, it’s very difficult to get these signals and that sense. So yeah, I think it’s a matter of combining, in the end you don’t do technology for technology’s sake, but to get some outcome that might be faster product delivery, happier customer, or happier teams, ideally all of those. But how do you get those signals and are you able to stay on top of all the other activities that you normally have to do? So these two parts come together.

You see contributes to happy teams, like what are the things that alleviate that pressure that teams face regularly?

Yeah, I think one is trust from leadership. If a leader trusts their team, that team feels empowered to do the right decisions, and no team or no developer ever likes micromanagement, I think that’s probably the last thing that’s on somebody’s mind. At the same time, from a product manager, team, VP of engineering, you want to know are we on track, do we do the right thing, how are things progressing. And again, if you’re not sitting in the same room, you don’t want to Slack somebody twice a day, hey, how are we going, are we there yet, are we there yet. So if you get these signals fed a little bit and say, okay, everything’s on track, I can see my epics are progressing, I can see our deployments are running quite smoothly, I don’t have to even interact in terms of asking people how we’re going, because I have the confidence. And you can build that trust over time.

And I think secondly, when it comes to major releases, there’s always a bit of a crunch time, so everyone’s busy, you find a lot of things in QA that you think you would have never needed to worry about, there’s certain features that might or might not ship, and not everything comes together at the very end, and I think that’s normal. You just want to make sure it doesn’t become the normal, that it happens continuously. So maybe you can see a spike in activity, things take a bit longer, certain things, people have too many PRs open, let’s say you have three PRs, four PRs open in parallel, that’s quite stressful, that might be okay leading up to the release, but afterwards you want to get into calmer waters again. So as a developer, I’m probably happy to keep up with this for a week or maybe 10 days before the release, but I don’t want to have this all the time, and again so it becomes a balancing act about being able to accept certain situations but making sure they don’t go out of control. And if you, as an organization, have the trend that points to the wrong directions, let’s say reviews don’t get done, things take too long, people maybe leave, that’s a different indicator, and I think that’s something we need to be quite cautious about and see what do we do that needs to be addressed more principally to help the teams and help the organization as well.

Yeah, so coming from my view of the landscape, deploying APIs, what you all offer can give me a lot of visibility and a lot more awareness as part of our release process across teams organizationally. But the other part that you touched on when we first opened is, and I find a lot of companies don’t see this layer, is our infrastructure has APIs, and that’s what really powers and fuels what you all are building, and so there’s a pretty huge opportunity to capture that data exhaust, you guys are demonstrating that on a daily basis, and then use that for intelligence and making sense of the landscape.

Yeah, look, one aspect, I don’t want to reach too much into the future, is basically also the cost aspect. You have a lot of infrastructure, can you marry up that infrastructure with cost, let’s say your cloud cost, do you know how much your EKS cluster is actually costing you, how does it scale? Again, you have got the APIs, but it’s probably different APIs and different systems that need to be married up. Let’s talk FinOps, for example, because it’s one of the ops dimensions in your introduction. How do you now correlate all this with your internal cost, and how much does a product feature cost you, and how do you feed that back into the whole lifecycle process? And again, when you have got all the APIs, you have the infrastructure APIs, but marrying up that data is obviously not straightforward.

Data-driven ops, but ops spread across all these different areas, allows me to be more aware but then optimize my spend, sounds like a pretty good opportunity for automation there as well.

I think so as well. And it goes back to, if you’re in sales or marketing, you probably use Power BI and have your BI tools. In engineering you don’t plan that way yet, but one of the reasons is because, old school waterfall, you never had enough data to make those decisions, your development cycles were quite long, they took months, then at the end somebody does some testing. Obviously even in the old days it wasn’t exactly like this, but you didn’t just get the short cycles to get enough data, and it’s really like infrastructure moving to agile, in a way you have got all these data points, so now you can help to smooth out the trajectory and move along towards the goals you just mentioned. And I think that’s really one of the changes why this more data-driven approach makes sense today, and probably it didn’t really make sense 10 years ago, because your development processes, infrastructure, engineers haven’t been really empowered running infrastructure, managing DevOps processes. So it’s already much more distributed than it used to be. Now with all these distributed information, how do you bring the overall engineering radar back?

This seems pretty key. I would say one of the top two asks I get from enterprise customers when it comes to the API landscape, kind of the highest levels, discovery, where’s all of our APIs, where’s all of our infrastructure, what’s going on, they just don’t have any visibility, and then governance, they want to be able to, because they can’t ever realize any governance because they can’t actually see most of it and understand it. So this sounds like a really, I was just reading one enterprise group, I won’t mention their name, but they’re saying, we have 68 teams who’ve all been doing their own thing for a number of years, and we got them to agree to a single gateway strategy and policy strategy, but they all have their own software development lifecycle, but we’ve got to figure out a way to start mapping that, understanding it, having our finger on the pulse of it, and then driving it in a specific direction.

Yeah, governance is a very good point here, and understanding, especially in the enterprise environment, what are you actually doing. There’s reasons why people have different software development lifecycles, they might have different back ends, different product lines, infrastructure, so they probably shouldn’t be exactly the same, but if you don’t have any visibility into this, that’s just a lot of chaos, and chaos always means it’s really unpredictable and you don’t know where to action this. And the governance aspect that you said, okay, let’s first gather the information about what we are actually doing, once you have got that information, you can start some discussion and some decision-making process. You probably don’t want to jump to conclusions in the first second, but you can see, okay, this is where we are at. And that’s probably in the API lifecycle very similar, I can imagine you have got people struggling with having, do they have APIs, what versions of APIs do they use, what about vulnerabilities in APIs, what’s the remediation path, all these different things, and again it probably speaks to different groups with different priorities, and there’s always fires that are burning, but which ones do you address more principally.

Yes, and responding, perpetually responding to whatever those application needs are, not the holistic, overall organizational strategy, and without much awareness of how other teams build things. So I can see the data being able to equip teams with this, just to get them being able to understand what’s happening, have visibility into other teams, and get notifications on what is happening, what is the software development lifecycle for those groups over there, and how can I learn from it, or how can they learn from me.

Yeah, very true. How does governance, how does Postman deal with governance, because it’s a big topic. Where do you even start, and what are the priorities that you see from Postman’s point of view? This is sort of my top three things, governance, that our customers would like to address.

Governance, like most things in the API world, means many different things to many different people depending on who you talk to, same with the API lifecycle, what’s the API lifecycle, you’ll get a different opinion from different folks. So governance tends to start with consistency of the interface, so the design and the patterns we use, and starting with REST, using HTTP 1.1, and then having common, whether it’s the design and everything. So that’s the widest swath of what people think is governance, and so at design time you try to apply certain governance, when you’re designing your API and developing it. But then the other side is a set of rules that will lint and check for that in the pipeline, so there’s like rules engines like Spectral that allow you to say every API has to have this header and here’s the rule, and then that gets put into the pipeline. So Postman is known as a testing tool, and you can write contract tests and run those against your APIs, and then put those into your pipeline. Governance is just kind of getting layered on that, so you’ll do your contract tests, your performance tests, your security tests, and then your governance tests, all is kind of a suite at the pipeline layer. But depending on how well your team’s been educated about those rules, why they matter, about good API design, you’re going to have all kinds of pissed off developers who hit the pipeline and it fails, and they don’t have any sort of visibility into the why. So I can see more awareness at this layer that you’re also going to, I think makes a lot of sense.

Yeah, I think that why is quite important, and it goes back to team culture, I think that’s important as well. So we’re definitely not the solution for everyone. If you decide clarity and visibility and sharing is not something your organization wants, then we’re probably not the right partner for you, to be frank here. But developers are hard to find, keeping developers is even harder, and that needs to be appreciated, and the same way that products are built more and more bottom up, the culture needs to be built in a similar way. And I think even more traditional enterprises, we see that changing quite a bit, because nobody just wants to be the coding monkey that’s told what to do without having input and understanding. People feel much more empowered when they understand why they do things, from feature to delivery to process, the whole why thing, why do I do this. If you see how you fit into this why and the whole end-to-end story, I think it makes a much better experience from being part of an engineering organization.

Previously I’ve been working in different organizations, from R&D to large enterprises to startup, and obviously in a startup organization you see everything end-to-end, so that’s great, anything you touch you see the impact of it. But the moment you scale and you move to a large organization, that’s difficult, but at least if you know, okay, this is the big picture, ideally beyond your annual company meetups or your QBRs, the more you understand, okay, this actually makes sense and I see where we are moving and why we are moving that way, and that might be just changes of the infrastructure, changes why APIs might be much more important, why we might become much more modular, distributed, running on different infrastructure, I think that all helps to get a better feeling and understanding, because as a developer of course you understand what the latest trends are, and if you see you’re part of that, that’s always a good thing, rather than, oh yes, my organization hasn’t innovated for 20 years and we still do it that way while the rest of the world moved on, and I think that’s the most frustrating thing, unless you really don’t care too much about your job.

Yeah, I think for me one thing I’ve learned in tech in the last 20 years is the scale of things, and it’s very virtual, it’s hard to see. People always ask me what’s an API, well, they’re difficult to see, and so anything that helps us see that but understand our position in it and then understand what’s possible. So do you feel like the type of awareness that this data-driven approach brings, can we set up different kinds of tiers of guardrails for developers based upon juniors, because we have a lot of turnover of staff and developers come and go, can we set up appropriate sets of guardrails for junior, mid, and senior level developers so they can experiment safely in an awareness environment?

Yeah, look, I’m not sure about guardrails, at least the different views and visibility. If you’re a junior, all this from junior and people on my team, they’re not so much interested in the end-to-end delivery, they’re interested in their task, whether their pull request gets reviewed, whether it’s stuck somewhere, whether they need help and reach out. So you basically get things around review coverage, latency, lead time to change, these types of things on a smaller scale level. Obviously if you’re a team lead or a bit more senior, you’d like to see a bit more end-to-end, and the small things you don’t maybe care about because these things are running anyway, so it’s a bit of a different view. Again, I think we’re not so much in favor of control but more about visibility and different views and different insights speaking to different stakeholders. If you’re VP engineering, you really don’t care about how quick Joe’s or Kin’s PR is going to be resolved, you’re saying, okay, how many people do I have on which features, and how quickly can we deliver those features, and how much does it cost me, and everything else goes down in the noise and you don’t need to see this, as long as you have a trail of evidence why that is actually the case. So you don’t get just the number of pretty charts, but you have the ability to drill down into this, and then see, okay, up to the lower level that you need, let’s say your build performance or the actual tickets people are working on, because it might be, yes, it takes a long time because it’s complex. So at least you have the trail of evidence to have the communication across your teams or with your team members, rather than saying I drive the KPIs or guardrails by some number, and unless we have 15 we’re not doing good, and when we do 16 we are great. So if you don’t have that context, that’s always, context is key.

So shifting, I know you depend on APIs for this data-driven approach across many providers, what are your biggest frustrations when it comes to having to run your business, support your customers, using other people’s APIs? Maybe outages, I don’t know if there’s been any outages for major providers lately we won’t mention.

Yeah, look, outages is probably not the main issue. It’s probably all the undocumented bits in the APIs, where the documentation and the APIs are not in sync, some surprising bugs where the REST API works okay but the GraphQL API doesn’t do the same thing for non-obvious reasons, or the driver using Python works, using JavaScript doesn’t work. I think those things are frustrating, and in general, just before building a product, for maintaining a product, is always version changes, behavioral changes, how do you track that, can you get notified in time that things are going to break. I think that’s some of the challenges. And then everything in the container, Kubernetes space, that’s always quite interesting because you’ve got a lot of things auto scaling, and if they don’t, why is that happening just now, it’s not yesterday, so anything related to timing, concurrency issues or something like this that might come up, I think that’s difficult. But I think top one is probably bugs and documentation, and top two I would say is versioning.

That’s the name of the show, Breaking Changes, so thank you for talking about breaking changes, always helps my cause. I don’t really believe there’s breaking changes, I mean everything’s a breaking change, but they’re just not communicated, things aren’t communicated and planned, it’s not that it’s a breaking change, it’s just you gotta let people know what’s going on.

Yeah, and even if you let people know it’s going on, having a release note somewhere hidden on your website is not something that somebody ever will learn about unless it’s too late, and maybe it reaches some Stack Overflow channel with a link back to that release note. So we recently had interesting experiences where people changed their access control in unforeseen circumstances, let’s put it like this, and suddenly we don’t get data in anymore, and really until you went to the vendor’s bug channel, you wouldn’t really see that. It’s a corner case we hit, let’s put it like this, but it’s something that wasn’t coming to our attention enough.

Yeah, it’s that visibility, communication, observability, that one of the areas I’m really focused on right now is the relationship between the API producer and the consumer, and making that as interactive in real time as possible. And Postman has what’s called public workspaces, so think of a public workspace, or we have private partner ones too, but you can have a portal like an API portal, but it’s for an intended audience, and it’s more than just your docs, it’s got your API monitors, your contract tests, the results, so you’re exposing more of your operations with the consumer so that they understand, they see the tests that you’re running, they have access to your mocks. So do you feel like at the data-driven layer, at source control and CI/CD, do you think there’s ever a potential for a view of that data that would be with your consumers or publicly, to show your velocity or reveal more data from behind your operations?

Yeah, look, I think our primary consumer is company internal. So we provide that information for your own organization. And for our own data collection, we’re a big fan of static typing, static analysis, so it’s basically the bit you talk about, contracts, to make sure that all the different bits and pieces work together quite well. For that internal development process, I don’t think we intend to share that necessarily with the customer. I can see that maybe, in terms of, if you’re a service provider and you provide bodies for some other company, you want to show, yes, I’m doing best practices, something around that case, it’s probably a bit of a different use case than showing your development process to the end user directly. For me as an end user, what I care about is that I get the right products that provide me business value, and I get them quick enough, how exactly they do that magic there, it’s probably secondary. Well, me as an internal company, I want to deliver, I want to create that magic, and I want to be consistent around that magic, so that’s what I care about. The other side of the consumer-producer contract, I want to deliver you the best product possible in the shortest amount of time, and ideally have a little bit of a profit margin there, and as a consumer I want to exactly achieve or receive that type of product.

Yeah, interesting, that again back to that API product manager, that feedback loop, and I’m always just fascinated by how it evolves, what it is in different industries, and so I’m lucky enough to have the show where I get to talk to people about it and learn the different ways. So back to what you’re seeing in your offerings, what do you see with customers, are they largely wanting, needing to do this on-prem, in the cloud, a hybrid, are they looking for VPC options, what’s the makeup of the landscape?

Look, it’s really a bit different. We are very much focused around cloud and people who already use SaaS or cloud products. You might have your GitHub, GitLab, Bitbucket, you use your Jira, you have your CircleCI, GitHub Actions, you have some deployment tools, you already have a lot of things in the cloud, and you probably made a conscious decision not to host your own infrastructure and not to build up your own data centers. So those are the ones that are our ideal customers, because they use modern systems, they already have APIs, we connect easily with that, those APIs become first-class connectors in our system. The customer can authenticate with their own SSO, token based, so we don’t need to know any of this, we don’t need to touch this, and it stays encrypted wherever it can, at rest as well as in transit, because it’s all your metadata and we don’t need to know this.

Obviously if you come to the top end of town, there’s still quite a bit that’s run on prem, they might have their own private clouds, and therefore for those we probably come to a more customized solution, because, as you know, in those situations nothing is out of the box anymore, because things have been growing over time, and as you said earlier in the discussion, you may have so many different teams that have different software lifecycles, typically they come in through acquisitions, mergers, the usual activity, they have different environments, so how do you harmonize this. And so we typically work with some priority plan, how we onboard them, what’s the most important teams, what do you want to onboard, and then yes, there might be still some, I don’t want to name any tools, but some old on-prem tools that probably are no longer supported, and you might or might not want to have that data there as well, or just focus on the next generation of your company evolution.

Yeah, it’s interesting, the incentives for people to modernize and move into the cloud. It’s one of the common talking points that I have with guests, their maturity, where they’re at in their journey, depending on whether they’re in financial or healthcare, and it’s always fascinating to see where people are. So in your journey, what’s the roadmap look like, what’s next for your roadmap, what are you guys investing in?

Yeah, look, I think the correlation with cost becomes much more pressing, and in this way I’m just talking cloud cost here, not much around people. Can you sort of, I want two things, can you measure how much does a feature cost me, how much does our product cost me, how does it scale with my user base, is that assumption, and especially moving from data center on-prem to cloud, how much do we depend on this. And if you have ever seen some AWS, Google bill, it doesn’t really give you a lot of insights around, back to product features, it tells you you use so much storage, you use so much compute, but how does it scale? So I think that’s one of the areas that’s really quite important. And the other thing is probably more on the deployment side, the quality aspect, how successful are your deployments, how long does it take you to recover if something is not successful. And maybe a third aspect is also, and you touched on this earlier, what about your customer sentiment, can you feed that in as well, let’s say you have some customers say, I never use that feature, why do you have it there, is there a way to feed that in. At the moment these are two disparate, separate worlds, and it’s not something I would say that’s on our near-term roadmap, but it’s something that keeps us thinking, what’s going to be the future, and how do we move from the internal data-driven, that’s one thing you have now, then you have all the observability, log monitoring and so on, which is a little bit your infrastructure external data-driven, and you maybe have sentiments on top of that as well, how do you marry up the whole thing. It’s not something that we’re going to solve tomorrow, but maybe the day after we should really think about how that all fits together, because again it goes from me to you back to me, how do we work.

Yeah, this is, having my API product manager hat on earlier, this is a common vein I’m getting across conversations here on Breaking Changes, but also with Postman customers, is strengthening that feedback loop when it comes to product management. So you talked about the cost, like tell me the cost of the feature, what does this cost, flip to the BizOps, throw another ops in there, what are we charging, what’s the revenue, what are we making off of this, how many customers are using it. Now you’ve got a really sweet feedback loop when it comes to me as a product manager getting what I need, which features stay, which ones go, how much did they cost us, and back to the predictability of all of this, that’s a pretty sweet spot.

I think there’s still room for more powerful APIs as well, how do you make that all API driven rather than having some salespeople or some other systems in the loop, and your Excel sheets that are kept in certain parts of the organization to manage all this, but how does it become a machinery crossing different organizational silos. So there’s probably room for quite some nice APIs.

Well, wow, I think we did pretty well for this podcast, that covered a lot of ground, but very valuable. I appreciate you sitting down with me today and spending time to talk about your view of the landscape.

Thanks a lot for having me again, and yeah, it was great to explore a little bit outside my usual scope, to see how you feed back from the enterprise clients as well, and how the API world and the data world, just really two things.

Yeah, this is what I love doing, pulling people out of their silos, I feel like that’s what APIs are about, is exposing us to the outside world, but then I get to learn about your world too and your views. All right, I appreciate it so much. Thanks again to Ralf for stopping by. You can find more about Logilica at logilica.com, and you can find Ralf on LinkedIn. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.