Techstrong TV – February 10, 2025

Hey, everyone got those post Super Bowl blues. We've got The Cure for what ELs you, you're watching Text Junk Gang. Hi everyone, it's Alan Shimo.

Happy Monday to you all. It's Textron Gang Post Super Bowl edition. Uh, we've got some, we've got some good stuff out from the webs that we're gonna talk about today.

Let me introduce you to who's talking about it. Um, our gang for today, we have, well, we have some regulars, but, uh, joining us, I think she looks like she's home out there in New Mexico. She's the CEO of Deploy hub and involved in CDF and OSSF and a bunch of other good open source stuff.

It's our own. Tracy Reagan. Hey Tracy.

It's good to see you. Good to see you too. Alan.

Great to be here. Thank you. Moving from New Mexico down well, to the west of Texas, down to the east side of Texas, down Houston way.

He is a FU analyst, CTO at Visible Impact Guy Courier. Hey Guy. Good to see you, man.

Hey, Don't, don't say Houston to in Austin Night. Austin, Texas, central Texas. Did I say Houston?

Not East Texas? Yes, you did. Well, that's right.

Love used. Love my Houston people. But I happen to live in, uh, the great city of Boston, Texas, central Texas.

Well, I, where we get warm Weather year round, whether we want it or not. Same here. I apologized to all my friends in Austin there.

I had a momentary lapse, I think it was too much Super Bowl stuff. Um, I was thinking you should ap you should apologize to the city of Houston, but what do I know? Yeah, well, it had something to do with the guacamole though, I'm sure.

Um, anyway, guy, wherever you're from and r welcome, um, Gonna be here. All right. And we'll move up from Houston to Austin to Colorado, our man in the Rocky Mountains.

Mitch Ashley. Hey Mitch. How are you, man?

Good. Doing good. Happy Monday, everybody.

Happy Platform engineering day. I think we're gonna be talking about that. Yeah.

Great topic. Cool. Mitch, you're still in Colorado, right?

I am, yes, I am. I have moved, moved, and I'm not traveling. He moved.

Alright, good for you. Well, and then we'll round it out with the, uh, the, uh, man in Harrison, our Chief Content Officer, Mike Ard. Hey, Mike.

How are you? I'm well. You know, I can't figure out which President Harrison is actually named after, but I'm gonna look that up.

Well, it, it could, I don't What makes you think it's named after a president? Good question. I don't know, but I've been here long enough.

I should figure it out. Yeah. Well, what are the, if it was a president, we've got William Henry Harrison, he's probably the oldest, right?

Mm-hmm. Then there was another Harrison Post Civil War with the long beard. Right?

That was William Harrison, wasn't it? William Henry Harrison. Yeah.

No, there was William Henry Harrison, I think is earlier. I think, I think one of them caught a cold and died. That's What I think.

Right? One of them died pretty quickly. Yeah.

Got a cold and died. But that would be an interesting reason to name a town after someone. There you go, man.

All right, well look, report back to us on that, Mike. Yeah, I will. I'm asking an AI get agent.

A ai AI agents conference. All right. Well, guys, before we jump into our first block, you know, for those at home, we don't do these live If you haven't figured out, we usually record the day before.

But being that this is a Monday show, we record it on Friday, well, we, so we've got what they call a weekend in the middle. And this weekend, as I mentioned earlier, is the Super Bowl. The Kansas City Chiefs are playing the Philadelphia Eagles.

So I, so I thought I would do a little experiment taking advantage of the time warp here. I'm gonna ask each of you to make your prediction for the Super Bowl score and winner today here on the show. People will see it Monday and real, and we'll see who was the closest and who was it.

Right? It's kinda like back to the future, you get to play Biff. Um, so Mike, I'm gonna ask you to lead off, what do you, what do you, what's your prediction for the Super Bowl?

All right. Realizing that I probably am not a fan of either one of these teams, but I'm going to, uh, go with the Eagles 27 21 over the cheaps Tight game, low score, relatively low scoring. I think the over is higher than that, but, okay.

Mitch, how about you? I thought you were gonna record this as, uh, two different endings to the movie. Like, which, which team won, and then we can Well, no, I'm, I'm just doing that for mine, so I I, okay.

You know, I, I come out Right, but go ahead. Well, you know, in, in, in a typically tight score, 13 to 14 weird score, you know, um, it, it came down to the, to the, uh, Kansas City. It was mahome at that last second to, to get that touchdown over the line.

And, you know, the, uh, the Eagles weren't able to stop 'em given their great defense. It was, it was a pretty amazing game. So it's 1413, you score pick.

Yep. Mm-hmm. Ooh, I love it.

Tracy, how about you? Well, it doesn't involve a hockey stick, so I don't know anything about it, but I can tell you what chat BT says. Okay, well that's as good as Annie.

Yeah, exactly. 5. So there you go.

Go. That's my prediction. Go thirteens pretty close.

So Kansas City by a point and a half, I could guarantee you it won't be by a point and a half. Yeah, that was a weird number. You know, half points.

I was, I was taking candy from a baby, You know, but, but, but, but now you put this whole idea of chat GPT as a bookie in my head, and that's a whole other thing. Oh, it has the spread as well. So if you wanna know that, let me look back again.

It says, uh, a money line of minus one 20. Okay, very cool. I'm not a, I don't, I'm not enough of a gambler to know what that means.

I'm sorry. I don't Either. I don't know that one.

Okay. How about you? Uh, I think the Chiefs 5, 9 35 to 26 with one defensive score by the chiefs, A take away and defensive score by the Chiefs.

So, alright, that sounds interesting. So I'm gonna go with my heart rather than my head, which is probably not a good move when you're betting, but I'm gonna pick the Philadelphia Eagles in a shootout, 42 to 36 a shootout, and there'll be some defensive touchdowns too here on both sides, either now there's gonna be turnovers. I think there's gonna be a high powered game, though.

Both teams have a good defense. Anyway. You're watching this on Monday, who, look, maybe we hit it, maybe we don't.

But Mike, let's move on to our first story for today. Why don't you, uh, take the reins? Yeah.

com. We invite you to go over there and check that out. 'cause there's a lot of awesome, great content starting to show up over there.

And it's a hot topics these days. It's a lot of debate about exactly what it is. And, um, there's, now the CNCF has a set of certifications that you can get to become a platform engineer.

And everybody's kind of trying to figure out, well, what does it mean to be a platform engineer versus, say, a DevOps engineer? Mitch, I know you're following this space and did some survey work on this last year, but what is your sense of what is the difference here in, because is platform engineering something a DevOps engineer does or is it an actual different job with a different title and a different role? Well, I think you, first of all, you have to take the certification to find out.

That'll answer your question. Uh, at least according to the CNCF. No, it, it's interesting, you know, platform engineering really kind of accelerated its emergence, uh, during the, the post covid, let's focus on developer productivity.

We need to get more out, more for less, you know, with our developer community. Um, 'cause finances are getting tight and things like that. And, and, you know, some folks, it's, we've been doing this all along.

This has been, it's this admin work, or we called it ops something or whatever. That's true of a lot of things, right? We do many of those things and then we kind of package 'em together.

I think the difference is we're playing d different kinds of disciplines to some of those tasks. And what has emerged to be is, first of all, making sure in particular developers, but also testers and others have readily real, readily, readily access to tools that they use and somewhat standardization on those, and also support of those tool environments. It, it's more than just, you know, hanging up a bunch of spurs on the, on the wall and say, you know, pick your poison.

Go, go ride one of those Broncos. It's no, it's, it's like, here, this is what we develop code and here's the id. You can choose your id, but here's the plugins to use.

Here's the, uh, you know, repository, et cetera. But it's more than that. It's also trying to create standardized configurations, maybe more secure configurations, supporting of those things.

It could be for your platforms for development, for testing, for different production environments. A lot of organizations run, especially if your SaaS company may run different versions of the same app right. In for different customers at different times.

So it, it's the other area where it's really grown into is also also blending and kinda merging with DevOps. A lot of platform engineering teams support all the DevOps tools too. Why separate those?

It doesn't always mean it has to be that way, but it's certainly kind of easy migration to move that way. Um, I, I wanted highlight too, Alan has started a new podcast, the DevOps platform engineering podcast with Luca, and I'm sure you'll talk about that, where they talked about, you know, the old adage of his DevOps dead and platform engineering is taking over. There may be a few stalwarts that are holding onto that adage, but I think most of us know that's not true.

It's really accelerating how we do DevOps and scaling it. I've got some, so Mitch, thanks to the plug the show is called the Platform Engineering Show, right? Plain and simple.

There's an interesting move here on C'S part though, right? They, in addition to rolling out their certification, they're also, I think it's only the first or second time at Q Con London coming up, where on Monday zero day they're actually having a platform engineering conference, you know, as one of the conferences that they do, usually on Monday you get, like all of the projects get to do their show. Some of the daughter foundations do a a, a gig and then some subjects.

In the past it's been, uh, security Cloud, native Security, and OSSF started this year. They're doing a platform engineering one. And from what I, uh, gathered, uh, Chris Ek, the CTO of, uh, cloud, CNCF said that it's, it's, it's like they're one of their most popular electives for that Monday zero day, uh, of, you know, lineup.

Actually, it might be Tuesday zero day, it's Tu no, it, it's Monday, then Tuesday. No, it's Tuesday. I apologize.

It is Tuesday. Then Wednesday, Thursday, Friday is the actual expo. Tuesday, zero day, not Monday.

Monday, zero day in RSA. But the point I was trying to make, what was the point I was trying to make, the point I was trying to make is my friend Luca, that Mitchell references Luca Ante. org.

They're the people who put on Platform Con for the last couple years, and it's probably the single biggest platform engineering conference. It's virtual. Oh, this year it'll be hybrid, uh, in the world.

They get 25, 30,000 people registered for that thing. Um, they've got about two to a hundred to 300,000 people on their community chat. And, you know, all of that.

They have all kinds of working groups and, and reference architectures and everything else. One of the things they have is the training certification course and platform engineering. org certification or course the right one for you?

Do you want to get both of them? Interesting? Usually these break off into the commercial versus non-commercial, the vendor versus the org kind of thing.

But here you both, you've got two not-for-profits, two, you know, communities with dueling orgs for what is, according to Mike and Mitch, maybe not as well as a defined a, uh, not as defined as some of the others. So, you know, I don't know. I mean, CNCF kind of has a bit of a minus touch right from there.

Yeah. Don't these things tend to run on vibes though? Like, you guys have been paying attention this far longer than I have.

I I feel like, you know, could be, you know, a movement, whether it's an anti CNCF movement or just a pro platform engineering movement because of whatever, like the purpose. There's a, there's a good, helpful purpose in this education certification. It's a way of someone saying, I I I I've studied, I know, right?

But the reason they're doing it is to get a job, to get a promotion, what have you. And the reason they're accepted is so that, uh, people hiring you can have confidence and that can come from multiple organizations, is just by vibes. I mean, there seems to be some sentiment that comes out of the soup of culture and community and all that stuff.

And one becomes the one and another one disappears or becomes the other one. Uh, it's, it's as random as that. No.

That neither of these organizations are gonna do a poor job of training and certifying. org, I mean, certainly today has a much larger community of platform engineers anyway than perhaps CNCF does. That's one of the things I was thinking, Alan, too.

org community is a very fervent, passionate, engaged community and kind of kinda like early DevOps days, but maybe even more so, just a really strong vibe building. Yeah, no, they've done a good job of, of organizing Luca and yeah. And the team there.

It may propel it to be the leading certification. Maybe it'll be unique and different that way. Maybe enterprises will look more to CNCF.

Who knows what'll happen. You know, I, I think the platform engineering certification though is more, you know, more of the unconference unconventional, you know, you may be able to just take the test and not get the certification, but I took the test kind of thing. 'cause you know, there's a, some people revolt with the idea of, of having a certification, you know, too structured down with demand.

A lot of them will say that the test is just people who are good at taking the test past the test. Oh, it's a DEI thing. It's a DEI thing.

I, that's where my head goes immediately when I think certifications. I was like, you know, I want someone who's gotten their hands dirty and done this. And even if it's in their own environment, they stood up a raspberry pie and they've been installing things and figuring out how to configure it and understanding how to start automating some of the configurations.

So, um, it doesn't, you know, it gets certified. It's a really good thing to do, especially if this is an area that you've not been in before. But we've had operations people and production control people for forever, right?

They've been there forever. So why is platform engineering a discussion now? Well, I'm glad it is because we have far more complex production environments or any environment test development environments than we ever did before.

If you think about a, a, a monolithic application being deployed to a Windows server, for example, pretty, actually, it's pretty straightforward and simple. And you can have a, uh, a either an SRE managing that. Uh, you can have a production control person or a a network engineer even managing that.

But when you start thinking about the complexity that we're going to see that we already see in just a Kubernetes environment, and then add AI to it with hundreds of AI agents that have to be configured with traffic going to all of them, that has to be looked at and managed on a regular basis. We are in a new world when it, when it comes to production control and, and what we're calling platform engineering. And it's good that we're, if, if it's true what Mitch has pointed out, that we may have DevOps and platform engineering in the same department, or at least working close together, I would love to see that because these platforms are built on a lot of scripts, and that's where we shoot ourselves in the foot or the face sometimes can be even more dangerous, right?

Because scripts are obfuscated, they're hard to go look through. And if we start doing more things in a templated way when it comes to platform engineering, we think of things like Terraform and, um, you know, open tofu. These products that are, are trying to help us through the process of templating and understanding and being able to repeat the creation of these environments, the better we'll get and the more prepared we will be for these broad AI environments, and it'll give us a better opportunity if we choose to, to move off of A-A-A-W-S environment and into our own.

So it's a, it's, it's the, the time is right, the conversation is correct and go get certified. Uh, because if you haven't done this before, we'll have more jobs in it. And, you know, the Ortel team, this has been such a discussion for them.

Um, one of our, uh, committers did eight, a series of eight blogs just to teach how to use all of these different tools. And there there's a lot, there's a lot to learn in it to get your hands. I'm so glad you used the, uh, you mentioned the SRE because I, I, I felt like, um, SRE had its moment and SREs were mountains striding, you know, uh, uh, infrastructure gods and goddesses who, uh, went around saying, you know, like, we, we are going to make your environment secure, solid and reliable and all that stuff.

So you keep doing all your fun DevOps stuff. And I, I, I was a little confused by it mostly 'cause the name and my impression was that the idea of platform engineering as it, as a discipline arose helpfully out of site site reliability engineering, because it reached up into what really matters, which is the application, its functionality, and what people are trying to do with it and with data and uh, uh, uh, uh, Rami Angar, uh, from Cloud Foundry, uh, uh, posted a really nice perspective about how the phrase platform engineering seems like marketing, but engineering a platform definitely is not. And I feel like it gi that name and that phrase marketing or not, gives us a really good focus on what, what is needed in this, as you say, increasingly complex, interconnected, uh, multi requirement host a requirement world for any application, which is somebody who is going to be not, not ensuring the reliability and functioning of an infrastructure, but someone who is engineering a platform to serve the business interest.

So I disagree, it's guy, they do have to do, they, that platform has to be reliable. Sure. But that's, that becomes that, you know, it, it almost subsumes the SRE function within the platform Engineering sre.

So look, these are all interrelated under this bigger umbrella that I call DevOps, but I've had a chance as part of doing this platform engineering show and talking to the platform engineering org people and some of the community there. It's not as nebulous as you think it is, and it's not necessarily just ops by another name and, and stuff like that. And it's not meant to replace DevOps in spite of what they said from a marketing perspective.

Here's the deal as far as they see DevOps is great, right? The, the whole kumbaya, the whole cultural, the whole idea of breaking down silos, working together, when you get to large scale, it's hard to organize that chaos. And increasingly with DevOps, there was the shift left shift, left, shifted, it left, shifted further left, not left enough, shifted more left, where all of a sudden the mantra became where the developer is building his own platform that he develops on.

And that's, that's when, that's when the, the stuff hit the fan. The developer shouldn't be tasked with building the platform they develop on. And wouldn't it be better if someone who is supposed to, who's certified, who is trained, who is experienced building a platform with the guardrails that allows the developer that then just develop, he doesn't have to build this platform or her platform.

They develop their code, their apps, and they go faster. So I'm just not sure where we're disagreeing, Alex, because I'm agree With all That. I, I would argue to a certain degree you would get a lot of folks who would say that's exactly how it used to be back in the day.

And then the developer guys rebelled and said, we're gonna go out and build our own tools and platforms because you guys are too slow. And now it feels like we're coming full circle. So people are standing there.

This isn't got the way of the world. It's always been, yeah, That started around 1970 with the PDP 11, like guess Yeah. We've always done That circle of life.

It's the circle of life Circle of, but there's a part of it, there's a part of this discussion about who's accountable. So for most of you out there listening, I'm sure you will know and, and experience this, is that if there is a production problem, who gets called to look at it and fix it, it's the application team. Even though they don't have access to production, they have somebody else who might be sitting there with them trying to sort out the problem.

So we created a site reliability engineer who could have more control, but they were assigned to a team. But as Alan points out, they were also trying getting, having them do the hard work of actually building out the, the, the platform. So these, there is a, there is something that we used to talk about called separation of duties, right?

So we've constantly tried to, to achieve that separation of duties by having an SRE who might have production access. And he's the person sitting on that team working with them. Yep.

That person should still be there. Yep. But there should be another team that is managing the platform itself.

These are very different discussions. I I agree. The platform is different than the application that they're managing.

So we need the platform engineers to start standardizing and, and, and stabilizing these, these environments in order for us to move forward. We can't move forward without having that. There's another thing happening here too, Alan, is I just wanna note that, yeah, I obviously talked to a lot of vendor technology companies in my role and, you know, as, as does Guy and more and more sort of platform engineering advocate is the new dev rail.

It is the, it is the focus of companies because things come together at platform engineering where it's developer tools, it's, uh, Kubernetes running and production are running the underneath the tool chain security is starting to kind of connect there as well. I'm not saying it's the center for all activity, but is a connection point now. And we kinda lacked that before when developers are creating platforms and doing all the supposedly operations themselves, but not, and so it's, it's, the market has responded to, I think, what's happening in, in the, uh, you know, development community.

Just as an example, the latest one I was at, uh, Dynatrace, uh, last week, Dynatrace perform, and you remember, and Andreas Grabner, our friend at the CNCF, he's a Dynatrace, he's now, you know, uh, uh, advocate for, uh, platform engineering. He gave a whole talk about it. And that's clear as I talked to different people at the conference, that very much, wasn't it Mitch wasn't Andreas, CEO state.

Um, he was at, and then he, I can't remember where he was before. Well, out of new new out of the Netherlands Yeah. With some of our, uh, uh, the cloud de marketing, some of the folks from there moved over there and, uh, oh, the, uh, um, who else was a, um, someone else was there that I saw.

Anyway, there were some old friends that we have, um, good folks that we have on different, different, uh, uh, on different, uh, things. Anyway, the po the point was, you know, it was a whole main stage conversation. We're talking about platform engineering and they're all, it is main stage.

Guys, we gotta move on to our next topic. I'm gonna take the prerogative here to have the last word. You know what, all these people you're talking about work in the software factory, right?

Kind of father knows best Dad went off to work in the factory, and they all work in the factory and there's a job there for all of 'em. And it takes, it takes the village to build our software and run it today. So we have SREs and platform engineers and DevOps teams and developers and testers and all the, all of the things we need to make software what it is until AI comes along.

And I'm only kidding, I don't know what AI's gonna do. We're gonna take a break. We'll be back in a minute.

Discover Techron group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us.

You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients. Let's revolutionize your tech journey.

Contact us today and tell your story to the world in the most powerful way with Textron Group. Hey folks, we're back and we're gonna continue this conversation a little bit with a little more focus on DevOps specifically. 'cause there's a lot of debate out there now about, well, does DevOps scale?

Is it broken? Other folks say, Hey, you know, look at all the great software we're putting out there because of DevOps. So maybe two things can be true at the same time, even though they're at polar opposites.

com, done by Port Inc. They are a provider of a internal developer platform. So they definitely have a stake in this conversation, and they only talk to, you know, very high-end teams.

But they found out that, well, developers are wasting a lot of time and more troubling still, it suggested that half of them don't trust the data that's actually in the DevOps platforms and tools. And that kind of stuck out with me is like, well, if I'm not trusting those tools, then what am I doing? Just calling up people and asking them where things are doesn't sound very efficient to me.

But Tracy, I know you've talked about this in the past where DevOps is broken, but the question I think is how broken, where is it broken and what, what can we do to make it better? Well, I wouldn't say DevOps is broken, um, but I would say that DevOps needs a bit of a tuneup. Um, but going back to that survey, I read, read through that survey, and sometimes things don't feel right to me.

And it may be, but one thing in there said that an average number of tools was seven. And I'm thinking seven. Just seven tools.

Is that all? I think it's missing two digits. I at least one digit.

Right? At least one digit. I mean, I probably can come up with seven tools right now just thinking about what you know, are in common.

DevOps pipelines takes Seven if tools to manage the 70 or 700. Yes. Right, right.

So that maybe it's, maybe It's seven approved tools and the rest are whatever I can find. Well, there are, we, there are so many. And that's the whole point of a DevOps pipeline so that you can manage the tooling.

Now, I know there's been to, there's been, um, similar tools that Port does, like task talk. And I do know that there is, uh, you know, having a layer that helps make this stuff easier is important, but I still don't feel like having seven tools is a problem. So I had to question, it made me question the, the, the, the data in Just still want the whole thing.

Yeah, I, But I'm sorry. Again, DevOps, DevOps does need to ha need, we're at a point that DevOps needs two things. We need to add security tooling to it, and we need to start adding what we need to do for, uh, testing, you know, LLMs and ML ops.

So while I, uh, you know, question the survey, I, I wanna point out that we do have a lot more tooling that we need to add to the DevOps pipeline. And seven is probably a li a very small number. And if you only have seven tools, you may not even need a DevOps pipeline.

Yeah, I I, but I felt Tracy, like, it was like, it was like, um, bad data supporting a good point or something like that. I don't wanna call it bad data. No, it was a Self, I dunno how they conducted this Prophecy.

So, yeah, fair enough. But the point is like, you know, I, I think the contention that developers, um, to, and, and specifically this is seven tools to build whatever build means. It doesn't mean to deploy or to, or any of that sort of thing, like necessarily.

Um, but, uh, the, the general idea that, uh, there are a lot of multiplying tools or let's say use the word platforms again, that developers are navigating on average. Um, instead of having something that's a little more integrated and seamless, if you like, um, that is kind of an issue. There's a lot of BYO there's a lot of stuff that's going on and I, I, I, the survey attempted to validate it in a poor way, but I think it's a real issue.

I do too. A hundred percent Chase, I don't disagree with you and I and Guy, I don't disagree with you either, but, but lemme that's, that's a set up. I just agree with that straight.

Hang on. I gotta write in my diary real quick. Alright, Lemme, let me just get this straight.

A software vendor who makes an internal developer portal puts out a survey that says, developers say, the problem is they've got too many tools, they could use a portal to help manage it because they don't believe the data. They're in metrics, in the tools and platforms they're using. They wish they had a portal to use.

And what do I sell? A portal? Come on, you wanna talk about self-serving much?

We, we, I think we already established that point. The point is, Well, I just wanna make sure we, we hit it with a big fat sledgehammer. The, the point is, the point is, in fact, we wouldn't be talking about platform engineering if everything was hunky dory in the land of DevOps.

So things are not Well, but that's okay. It doesn't have to be hunky dory. Life isn't that way.

It's not all unicorns crapping rainbows. That's not what the way the world works. There's gonna be issues, there's gonna be problems.

We keep working at it. We, we constantly improve continuous improvement, right? Iterate, reiterate.

Now that being said, here's where I do think you have problems in the DevOps toolchain. As you get to the enterprise level and you're at enterprise level DevOps, it is a very rare burden deed where you have a standardized tool set, whether it's seven or seven, you don't have standardization of tool sets in your DevOps tool chain because this team chooses to use Jenkins. This team might be doing GitLab, that team's doing harness uh, testing.

I'm doing t tricentis, I do sauce, I do pure open. I, I'm, I'm running coop here, I'm running VMware there. It's the enterprise.

We don't have standardization of our tool sets. Well, Alan, just, just keep in mind the punchline here, which is supposedly 15 hours of loss productivity per developer per week. But if they use a portal that gets cut by 90%, well, Yeah, sure, but that, that's the, that's the who cares part of it.

Because, you know, part one part is the, it's a culture. Uh, you know what? Innovation, freedom, trying things out, break fast.

All others, or you do wanna enable that. So is it really 15 hours of wasted, wasted based on what, you know, like what's the Point? I I don't think it's 15 hours wasted, but here's the point in my mind, there's this eternal combat between let's get efficient, let's slim down.

I want one throat to choke. I want less tools. We got too much, too many different software here, too many different security tools, too many different DevOps tools.

We've gotta, it's, it's, it's, it's wasteful. It's inefficient. We've gotta standardize, we've gotta standardize until I buy the next company.

And they have their own way and they dig their heels in that they're not going to, you know, this is what they use to go change. Something's gonna be a major to do it. It's the way DevOps evolved, right?

DevOps very rarely came from the top down enterprise wise. My theory always was we, DevOps came in bubbles. And you know, like when you're a kid playing in the bath with bubbles, as bubbles come together, they make bigger bubbles, and then they get bigger bubbles and then they pop.

And that's how DevOps evolved and that's how DevOps rolls out in enterprises there. They're these bubbles of teams that use their own recipe And they, and I think sometimes the, the mistake that we make is thinking about DevOps as tooling. When if we really built a DevOps, uh, framework, it wouldn't be based on the name of the tool.

It would be based on the, what we're trying to achieve at each state in the process. So a compliance scorecard, for example, so that every team can build their own DevOps pipeline because one's doing Java, one's doing Python, somebody else is doing rest. Because these environments are very, very different.

The compilers are different, the tools are different, but you can still define your compliance levels that you need to achieve. And we will end up with lots of tools. It's just going to happen.

And there's probably another 10 tools that we're missing in the pipeline just to add for security from repost scanning and signing to gathering, uh, data to doing vulnerability management on the out on post deploy. There's a lot of work we still have to do, but every single environment's gonna be a little bit different. Even an SBO different.

Lemme share, Just look at the data with you just to give some perspective. 'cause I'm wrapping up a new survey that'll be out probably in about three weeks. But we, we asked organizations, where are you on the maturity curve, both for DevOps and for platform engineering?

And interesting, they're almost exactly the same in terms of the phases. The, the way I've always characterized it as other than, you know, once you're past the getting started phase, you go into kind of operationalizing how are you using it? Different teams are doing different things and learnings, and then you enter this standardization phase where you start to boil it together, right?

Especially in the larger organizations. Eventually you get to what you might consider your own level of mastery. And both for platform engineering and for DevOps, they're both right about 44, 40 5% in that standardizing phase.

This is at the same point in time. At the same time. They both say they're about 25 to 26% in the mastering phase.

So they're really in sync. And I think that's not by accident. Um, you know, these are talking to the same organizations.

So I think they're moving together and, and, and fortunately I think that Al also says that DevOps isn't staying stagnant, whether it's platform engineering kind of bringing it up, modernizing it, or they're both just heading in parallel and their kind of paths and working together, whatever the per whatever the reason, I think it's a good outcome. But that's what the data says, right? I'm launching a new, I'm launching a new platform engineering, Um, platform.

I'm gonna call it Mr. Bubbles. Okay.

I like that. I swear know where someone already had that name. I just wanna know, uh, I, I don't want, I don't wanna know the source of those bubbles, Alan, but that's a whole nother thing.

Well, you never, you never played with Mr. Bubbles when you were a kid. You didn't have Mr.

Bubbles. Yeah. And, but I know that's not the only place that those bubbles come from.

It was like a little purple box with all the bubbles. He had eyes like googly eyes and your mom would pour the powder in. It would make all those bubbles.

As long as they're purple blood. I so sorry For you. If you didn't have a, a night with Mr, There's some things we just didn't have out there in the cornfields where I grew up, you know?

Oh heavens, the cornfields. I didn't grow up in Corn. Meanwhile, I'm thinking of Scrubbing bubbles Mr.

Whole time. Tell the truth Guy, you didn't have Mr. Bubbles.

Oh, I had Mr. Bubbles. Yeah.

Come on. You had bubble Mr. Bubbles.

Of course We had also had Scrubbing Bubbles Afterwards. Used the name. So of course we had, yeah.

Oh, that's all we got. Alright. What can I tell you?

All right, Let, let's Take a, explain A lot of thing about Nebraska. There you go. Yes.

That does. Poor guy never had Mr. Bubbles.

Imagine that. No wonder why you would make your jokes about other bubbles. Necessity's the mother of invention out there.

Just, just saying. Just saying. Okay, we're gonna take a break.

This is degrading quick. We better. Let's get it together.

We'll come back for, uh, part three of our episode today. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of security bloggers network. All right folks, and we're back with more IT issues. And this time we're talking about the eternal quest for the unified IT platform.

And you gotta wonder if this is a unicorn or not, but JumpCloud has a annual survey out talking about how this is what folks really want. I'm just not entirely clear it's gonna ever be possible. Guy, you've been following this a long time.

Now we have more tools and platforms across all. It, it's not just DevOps or platform engineering. Is that just the way it's gonna be?

Or can it one day get rationalized into some Uber platform? Uh, without mentioning ai, no. Maybe with mentioning ai, no.

I think, uh, how many times have we heard the pitch for the so-called single pane of glass thousand times, 2000 times? I think that, um, back in the day, uh, I led most of my Forrester research. There was a really helpful ship to thinking instead of the single pane of glass, the preferred workspace, and thanks to the cloud and the rise of the API economy and all that other sort of stuff, we do have real possibilities there.

So let's back up a step on, I, I read the story and, uh, the, the specifically it was for device, uh, and role, um, management, um, some and identity management that there was a desire for a single tool, unified tool. But it does bring to mind the perpetual 'cause I be, there are other service methods, fact, I just conducted one myself. Um, where there's a strong desire for unified, uh, management.

Let's say forget a tool per second or painted glass or portal unified management of let's say ser uh, service health or, uh, infrastructure health or whatever it is. Here's what's working against it. Two things really.

The first one is, uh, it itself is not unified, particularly they're security experts and networking experts close to each other, but have different agendas and need their preferred tools to help or their preferred single platforms. Um, there's, you know, identity management device management, which are related to security. They're all related to each other.

Um, but even in a small shop, uh, there will be, for example, vendors and consultants who are helping to manage certain elements of it that whoever you happen to have in your IT shop can't do or shouldn't do, or you don't want, you don't wanna hire to do. So you're having multiple roles here. And even a lot of these, you know, really comprehensive, uh, it service management platforms like ServiceNow or DMC and so on and so forth, um, they, they, they struggle to unify operations for the simple reason that as, as this is the second part, which is that as, uh, the nature of infrastructure and application delivery and so forth evolves, uh, there are new specialty tools that come up because the big unifying tools can't do everything everywhere.

So the API economy helps put all these together, but I think the idea of, um, unifying is the unicorn and maybe a, a helpful nor north star for everybody to think about, um, how to, uh, manage their entire estate and their whole landscape. Um, it, it, you know, how to put things together so that people, individuals and talents that they have on staff as well as developers, as well as business users to a certain degree, can all have their way of doing their jobs that still somehow interacts together with each other. But that is complexity and it will be a perpetual struggle in every operations team to, um, make things easier for the users, easier for them.

AI does show real promise in this area because it can do analytics including predictive analytics on very large data sets. So a large state doesn't really phase it particularly, and it helps concentrate the human operators on the areas that the most interest and concern, whether it's, you know, uh, device management and security or, or, or system health or any of those other sort of things. But in the end, unless we go down the rabbit, uh, sat Nadella told us that we're just gonna have our AI buddies and, uh, we're not even gonna be using portals anymore, which is a, not even a unicorn, a mirage.

Uh, no, we're, we're, we're, we're not gonna get there. Well, I, I just, if you aren't aware that February 28th this month is, uh, when we have the Great Planet Parade, and that's when we'll have a unified platform. It's when we have Neptune and, and, uh, Pluto, I guess, and all the other planets line up.

Pluto's not a planet Mitch. It is, it's still a planet, dammit. And in Nebraska, it's, I guess where they don't have MR Bubbles.

But either that, either that or it won't matter anyway, because in, in 2032 in Asteroids can hit Earth and even if we had the platform, we won't be here to enjoy it. But no, actually I did find there is one platform through them all. It's Called Precious.

Oh, okay. The one ring is, uh, yes, is not, is not here. It's the one platform, One of the ring.

This is the pendulum conversation, right? We need one platform, we need more tools. Oh, I'm hypnotized more hypnotized.

I don't think it's a pendulum. Uh, Mitch, I think that this desire, it has been perpetual. You ask people, you've talked to customers probably more than I do.

Um, I talk to a fair number of IT ops folks and they all want it. But then when you dig in a little bit and find out what the one platform is they want, it's actually the one platform that covers this part of the, the infrastructure. Is it from this other sort of Stuff?

Is it from Microsoft or is it from Azure? Okay, let's let's decide that first, right? I I don't know if it's one platform they're looking for.

I think what they really want is a single place to go to find out what tools they can use, right? Because there's more than, you know, a handful as this survey indicates. And we did, we've done that.

We've had c MDBs in the past where you could say, Hey, I'm gonna go stand up my environment. I'm gonna download this version of Oracle. Or tools like, uh, bit NAMI that, you know, made an effort to pull together.

This is where you can go find these on these different, um, repos. And I, I feel like that's really what they were talking about more than having a single platform one ring to rule them all. And I understand that.

I understand that desire, but we've done it. And I don't, I don't, I don't think anybody's gonna spend money on it internally. I don't, Let me see if I could bring some order to the chaos here.

I think you were gonna say something else, but go ahead. No, no. So cut through the, anyway, yeah, let me cut through to the, to the, to the heart of this.

First of all, shout out to JumpCloud for doing this, right? For those who don't know, JumpCloud is founded and CEO by my good friend, Rajat Bava. Raj Mitchell and I co-founded Still Secure 25 plus years ago.

I've been involved in Junk Cloud on a personal level since the day they started it. And know a lot about who they are, what they are, and what they do. And I'll shout out to Greg Keller too, their chief strategy officer, another friend there who's does great work.

So hi to Greg and Raja, if they're watching JumpCloud wants to have a directory that rules them all, right? They, they think ad active directory, it doesn't work in the cloud era. It doesn't work with Max so well, it doesn't work with cloud resources, it doesn't work with iot, with machine, you know, AD has has had its day and they want a cloud directory.

It's a directory to rule them all. And why having that directory is, is not just identity based so that when you log on, I know it's Mike or Guy or, or Chay or Mitch, but it also makes it very easy then to give you access to my tools to, to your tools that are pre-approved on the corporate land, right? 4 tools we spoke about on the last segment.

And you, you know, I don't want to use the word single sign on, but single sign on, right? And so does that sound appealing that no matter what device you're on, where you are, I could sign on and automatically get access to my tool sets and files and everything I want. Yeah.

Surprise, 85% of people want that. Shocking. Mm-hmm.

Shocking. Well, I think the issue comes more towards, you know, and I remember having this conversation last year with a CIO in, in New York who was particularly colorful about it. And he was saying, you know, the problem when every time I get a new frigging tool is I gotta go hire somebody else to go manage that tool.

And then everything in the costs all go up. So he's like, you come to me with a new tool. He says, forget about it.

I don't wanna hear about no more new tools. Was he a CIO? Is he a construction guy?

He's a, he's a, he's A, he's a, he's a Hardcore drop them over here. He's a hardcore New Yorker who was not having it anymore. And he was saying, you know, I, I have these platforms and if I need something, I'm gonna beat them up to give it to me as a feature.

But I am not adding any more new tools. He was Adding about these guys In your tools, you guys, guys Tools. I think we're talking about two different things though.

'cause one that you're talking about, Alan, and I think you touched upon as well, Tracy, is is features, capabilities, uh, uh, them being cross platform integrated, that sort of thing. My lens on this is RA really the, the operations standpoint. I think the desire, I know the desire for single tools or unified tools comes from a craving for visibility and abil and an ability to be proactive.

Because what none of these folks want CIO VP of, uh, ops or infrastructure, um, application managers, uh, enterprise architects, they, they, they, they dread the midnight call. They don't want the midnight call anymore. And what they fear is that they have these six tools and these six people on the six tools, but then tool number seven happen to have a yo-yo working that day and didn't see something and trying to, the comprehensive idea is that they can organize all of it in one place and see everything going on in one place and they get the little red lights in advance and they help fix it and they're being proactive and they get few or no of those, what happens?

Something's down, everybody's gotta pile in and figure it out. I think that's what, what it's really from the operations standpoint, that this desire for uni, it's to give for unification comes from, is to get a full and complete view. Not of what's happening now or what happened just a minute ago, but you know how to ensure service health for the whole stack going forward.

And every time you add a tool, you don't do not just adding a person, you're adding a, a dis uh, an interaction point on a potential weak link in a chain. All that sort of stuff. That's, and, and they hate that.

They hate that part of the job. And the part that the time when this is the most critical to have this kind of a unified platform is when you're onboarding new employees, you want them to be able to come into work and in a few days have everything that they need. And, you know, I've seen organizations take two or three weeks for, uh, a, a single developer to get all the tools that they need.

'cause it takes so long to figure out what it is that they should have. So there's a point in time that this becomes super critical and then you forget about it. Yeah, no, I think we're back.

And, and I think that is the jump cloud kind of vision right there. Tracy guy listening to you, I'm reminded of, back when I was in inter reliant in the late nineties, we were in a SP and we had this whole lineup of apps. We were hosting Oracle people, so PeopleSoft, Onyx, you know, late nineties apps, pre-cloud.

And, and we were trying, and we actually called it a miracle layer that would sit below all these apps and let us manage them, provision them, bill them, you know, do everything from a unified platform and that we would be able to plug more applications into. As you know, they pop up, pop up. It's a bit of a holy grail.

I I don't know if we ever quite find that. I think we're really talking about two things. One is, you know, there is no one one tool that's gonna solve all the problem.

Yeah. It just, not, even if there was, it wouldn't stay that way, right? Something else would come along.

It would be that would disrupt it. So we really have two things. We have, we have portals that get to help you with that onboarding.

Here's the set of tools, here's the capabilities, here's all the stuff that you need to kind of get started, right? You don't have to go looking for tools. The other, the other trend is towards what you're talking about, Alan, which is platforms, which isn't one thing to rule them all.

What they are is a set of pre-integrated capabilities, usually from one vendor that also shares data across those tools. So you're not, and also between the integration and the data, you're spending less time in the tools management, integration support business, but they all have to have very rich integration capabilities and not just lip service to integration to third party tools. 'cause people use other stuff.

Maybe there's testing capabilities in the platform, but I'm a tricentis customer. We've already got all of our stuff built in into that and or to, to whatever tool for security, et cetera. There are some things that you want, one of, you want one directory or at least a federated set of directories, right?

That you want one, you want one, uh, I, uh, ID identification or ID management of people, devices, things like that. You want one sign on? Well, there's a capability kind of tie those things together across applications.

But even those aren't one platform, right? Those are oftentimes things that are tied together. Uh, I don't, I don't know if I agree.

I, I think, I think the single platforms of Kyra, I think that that being able to manage ad plus JumpCloud plus whatever in one place is both possible and desirable. It's just when you start, like you, when you start to add more and more things that you're all seeing in one place, like you say e even if you succeed innovation, you know, uh, uh, puts that at a date, but yeah. Yeah.

But I, I think, I don't think it's settling on. I mean that's one approach, the single source approach, settle on one directory, just stick with that. Um, but also, uh, being able to, uh, add or use other, um, other directories and, and, you know, uh, identity systems while still not, without having to add a separate way to, to operate them.

That's more the goal here. And I just wanna open up a issue in GitHub so my platform engineer can set, set my environment up and I don't have to think about the directory. I wanna be served my environment and that's, Yeah, no, I absolutely, well, Is important Talk.

Doesn't that go back to the, or like when I first got involved in tech, I was the mantra of it. Our customers are the employees, the developers, and we serve our customers. It's an internal customer changed over the years, but it's still true.

Anyway, guys, we're, we're over time. I gotta pull the plug. Um, what a great Monday back to work week.

You know, I still think we should have a national holiday after the Super Bowl, but, um, we hope you enjoyed the show. We'll be back tomorrow. We've got a ton of great text drunk TV following this today, so check that out.

But until tomorrow, on behalf of the gang, have a great day everyone. We're outta here. This is Textron tv.

Hey everyone, welcome back here to techron tv. I've got a new company to talk to you about. They haven't been on our show before and it's the first time guest, I just met him, his, let me introduce you all to Chaz Ballou.

Chaz is the CEO of a company called Conveyor. Hey Chaz, how are you today? Hey, Alan, good morning.

Nice to see you. Good morning. Welcome.

So, I, I guess let's, before we get into conveyor, and there's a lot we're gonna unpack here, Chaz, let's start a little bit with you though. You're the CEO there. Um, give us a sense of, you know, how you came to be the CEO of this company.

What, what's your journey been like? Yeah. Uh, well, again, thanks for having me.

Um, my journey, I grew up in the Midwest and always knew, uh, you know, just hacking on computers and very typical story, you know, middle class, born in Detroit, grew up in the Chicago suburbs, and grew up, you know, playing computer games, then getting interested in programming, then building computers, and was just kind of in place, you know, for the early internet. And that first wave. And I know, always knew I wanted to, you know, build a software company and, and make a living in tech to go to college.

I really wanted to go to Princeton and run track and cross country there. And, uh, to make, make that work, I did an ROTC scholarship and signed up and served in the Army for, uh, four years on active duty in Washington dc. Good for you.

Yeah. Well, thank you. Thank you for your service.

Thank you. Yeah. Um, and it was a, it was a, a very, uh, interesting experience.

I, uh, before doing that, I went to law school. So when I was on active duty, I was a, a lawyer in the Pentagon working at the Army Office of the General Counsel and Jag. I was like, yeah, exactly right.

Yeah. That whole world, we were working on the, um, not on like UCMJ or you know, court martials or like Jag stuff. We were working on Army, like Pentagon stuff.

Like, you know, what bases go where and how are we doing, um, all kinds of stuff. The particular group that I worked in was anything to do with any land and that the Army controls. So all, all, you know, all kinds of stuff from basing and what bases are opening and closing to what can you do on a firing range to what, you know, how do we build new, uh, bases or how do we tear down old stuff?

Like, you know, you could have all kinds of stuff, housing base, typical base stuff, but you could also have weapons, munitions, explosives. The Army has a bunch of stuff that's like beyond normal, uh, real Estate. Yeah, no, it's not your usual land use kind of zoning.

Yeah. You know what I mean? And we also had it's Commercial or residential.

Yeah, yeah. And we also had, the Army also runs, um, the Army Corps of Engineers. So we had a ton of stuff related to, uh, army Corps, including, I mean, everything from Katrina and the Katrina litigation that was a trillion dollar combined litigation, stuff like that to, um, you know, when there's a flood and the Army Corps of Engineers decides or decides not to blow a levee and flood a, you know, flood a field or stuff like that, that all gets turned into, uh, takings claims, constitutional claims, and, you know, claims for, hey, let's, um, let's I In domain and stuff like that.

Yep, Exactly. Yeah. So we, I mean, I, I could, I could tell you all war stories for hours about all the interesting, weird stuff.

Um, but that was, uh, for four years and the whole time I was doing this, thinking, okay, I'm gonna have a whole bunch of interesting experiences and background for when I go start my company and work in technology. And so, um, 2013, I got, I, I had gone to undergrad, gone to law school, served four years in the Army, and I got out and immediately started my first company, uh, company called Adaptable, which was a, we started it, uh, as a secure HIPAA compliant cloud hosting platform that runs an AWS. And we sold it to digital, uh, health teams and said, look, this is like HIPAA compliance in a box.

And we, we took that through, we did a Y Combinator in 2014 with that and raised a Series A and, uh, got that profitable, like nicely profitable and good for you. Yeah. And my co-founder is still running that.

And in 2021 we said we had this profitable growing business. Um, and then also we saw the opportunity for what was going on with Conveyor and what Conveyor became, which is trust building. Or, uh, you know, how do you prove to one of your customers that they should trust your security posture?

We saw that at Adaptable in 2021 and said, let's split our bets. Let's take the profitable company and the hosting thing and get it out, you know, into its own vehicle. And let's take this wild card, which was conveyor this totally, you know, seed stage idea, but really interesting strategically in that what we were seeing was adaptable's customer base is small, small companies, startups, and the customer is engineering teams.

'cause they're buying a DevOps platform. And what we started seeing with Conveyor was big companies with big teams and big problems with communication and how they get their story straight. Like, our customers, like DocuSign or Workday have thousands of employees.

They have hundreds of people on their sales and security teams. How do they all get their story straight and make it as easy as possible for their customers, which could be big banks, fortune five hundreds to trust 'em. And that is, um, that's still what we're working on with conveyor today.

Uh, so that's a bit of what a great story. Yeah. My background, how we, you know, I'm, I'm a basically the two time, you know, software founder here, and conveyor is the latest iteration.

I think the, I mean, that brings us up to AI today and what's going on today, which is just that we started conveyor in 2021, working on a lot of it was like Salesforce automation and automating, getting an NDA signed and automating, getting customers secure documents. Like, oh, you have a SOC two report or a pen test report, or, you know, like collateral that your sales team has been given. And then you gotta get that to customers.

But it also, it's gotta be secure. It's gotta be authenticated. You want sometimes, uh, you know, like timestamps and water watermarks and you know, hey, confidential, don't distribute this type stuff on the documents.

So we started, um, with all of that in 2021. And then, yeah, just what is happening with deep learning and AI has come in like a freight train and it's getting stronger. You know, the rate of change and the rate of capabilities increase is really astounding.

And we, we started in 2022 using, uh, AI to do rag flows and fill out paperwork and say, okay, so you got, you know, you got a security form from your Fortune 500 customer, it's 300 questions long, it's all embedded in this Excel sheet. We started making software to go and do retrieval, augmented generation, look at a knowledge base or your database and then draft new answers. And getting that right has been really fun, really rewarding, difficult technically, but also pays off in huge ways for our customers.

7 on average. 7% of the time. Like first pass is perfectly accurate.

Like, it's like, put it to bad accuracy, which is given how security, like, there's a lot of sometimes, uh, bonkers questions or a long tail. So 95 is actually a approaching per, like, as as good as you can get. We think about 97 is about 3% of questions are just on average gonna be kind of off the wall.

Like you, you won't really be able to like fully predict them. And so as you get to like 97% automation, you start, you know, that's like as good as you're going to get. That's bad, certainly superhuman.

Absolutely. com days. And, um, we were doing hosted Oracle and PeopleSoft and all these old applications before there was cloud, before you had multi-tenant, all that stuff.

And we used to think if you got to 80, 85% it was superhuman. Mm-hmm. Right?

The other 15% is always just craziness, quite frankly. Right? It, it, it's total one-offs.

Just total one-offs. Right. And so, you know, anything over 85 97 is, is ridiculous.

It's just ridiculous. So let me ask you one quick question though. So did you run track at Princeton?

I did, yeah. Yep. Good For You, man.

And 5K and, yeah, Very cool. What a great story. What a great story and what a great lead into conveyor and, and, and what you're doing now.

As you mentioned ai, I mean, the whole business process automation and low code, no code, and so many other things are being disrupted here, but whether, you know, sometimes it's better to be lucky than smart, but whether it was luck or, or being smart, you find your play, you find yourselves in a place where agentic AI actually is gonna help you because it, it's kind of what you're doing. Before there was ai, before there was agents, now you can really accelerate that through the use of AI agents, correct? Yeah.

So we look in, we were talking, you know, form an up, we're talking a lot about, about this. com today and go to our website and look at our use cases, you'll see that we're marketed as automating security reviews and security questionnaires. And we're really targeted towards that.

And all the time we get asked, will you do RFPs too, or RFIs or, you know, how are you gonna handle that? And that's a big part of what we're doing this year is expanding, um, those, you know, use cases. But fundamentally what it really is is automation.

It's workflow automation, and it's a specific kind of workflow. The specific kind is the, when your customers need answers to sometimes technical, sometimes legal, sometimes compliance questions, and they're putting it on their paper and they're saying, Hey, I need your answers to this. I need you to basically ver you know, attest to the answers to these.

Sometimes that gets pulled in explicitly like into an MSA where they say, okay, here's the security appendix and you promise that, you know, it's a violation of our contract. Or sometimes they're just sent in procurement and there's no explicit attestation that, hey, this is part of the contract. But oftentimes these things have, um, the, the stakes matter, like the answers need to be correct in a way where with a lot of internal tools, AI doesn't need to be a hundred percent correct.

'cause you're gonna have a human who looks at it and is like, okay, well thanks. And then decides what to respond to the customer. But the kind of software that we're building, the goal you mentioned, you mentioned like, you know, what are we doing is to fully automate all of the work that your customer needs to buy you for these, you know, clear you as a vendor for these kinds of processes.

And a big part of that is when they have a form for you to fill out, filling out the form and getting really high performance on that. But a much bigger part of that work is all of what our customers call, like, the stupid work around filling out the form. So it's what happens before you fill out the form, which is, you know, the sales team sends over five different documents and only one of 'em is a security questionnaire.

And they said that there were two things for you. You know, like stuff like that. It's like, wait a minute now you gotta go back to the sales person and figure out what's going on here.

That kind of stuff. So you haven't even gotten to the point where you're gonna use AI to blast through one of these forms. You're just doing the stupid work around coordinating or AI comes back and it's like, well, we don't have answers.

Well, who do you talk to? Well, what kind of questions are they? Oh, it's product questions.

Now we gotta track down somebody in product management, right? And like, get the answers or figure out have things changed, all of that. Do you see what I mean?

Like, that's all the work around, even if you have a, a magic rag tool or a really great, you know, form filler like we do, there's still so much other work around that form filling, getting ready for it, figuring out what happens and how you, you know, how you complete the whole thing. And that's what makes Agen AI so exciting. And that's also what makes, because it 'cause what we can do and what's working is you take all of that stupid work and you really break it down.

You really break it down into excruciating detail. You really, you blow it apart into literally like a thousand different pieces. And they're, you know, they're organized by each of these, each of these parts of stupid work can sometimes involve a bunch of different decisions, but you can really break down the decisions and then you can build code and AI working together like scaffolding and calls to models that together can process this cognitive architecture or this decision making flow.

But using AI to go through and do it and breaking it down gets you really good results versus one trying to one shot everything in a big prompt and say, you know, hey, like, here's a bunch of context. Get the answer right or, um, make a decision. So anyways, that's kind of getting into the weeds around how to get good results out of this.

But the big news is it works, it really works, which is incredible. This is software that's never been possible to build. You can never build software before that makes good decisions for you.

I mean, look, which is, look I've known, I, I per Chaz I've personally known at least three different entrepreneurs who over the last, let's say 20 years have tried to, you know, using BPA kind of stuff, have form fillers, if you will Yeah. In different ones. I've seen them in real estate, in medical, uh, in, uh, well, one of my friends actually created the first mortgage application that you didn't have humans involved in.

Right? That was pretty cool. Um, but, you know, the whole ai I ai potential to just really disrupt this whole thing is, is crazy.

But you said something early on that I wanna come back to as we, you know, round out our time here. And that is, all of this stuff is the means to the end, but the end is building trust between you and your customer. And I don't mean conveyor and conveyor's customer though, that's part of it.

But, you know, the, the people who are using conveyor, it's their companies building trust with their customers. Because at the end of the day, that kind of makes the world go round and round. Yeah.

It's essential. And we see it with, you see, you know, security reviews and building that kind of trust. But we also see our software being used for RFPs and RFIs and other types of trust.

Like we started, I I, I mentioned this briefly before, but we, um, we started seeing manufacturing companies and agriculture companies. We have a freight forwarder, a logistics, like a shipping, a trucking company, basically using our software. And they're getting basically these, again, these forms they had to fill out.

Sometimes they're called RFPs, RFIs, sometimes they're called quality management questionnaires. com is still very much, Hey, this is designed for security compliance automation. But what we're, what we're seeing is that the underlying technology to represent the data involved in an a, a organization with multiple products, a bunch of different, you know, usually dozens of people on the sales team, a dozen people on the security team, several different people on product and engineering.

Uh, Workday is our customer. They have 12 different product lines across three different subsidiaries. So being able to take all of that complexity and wrangle it really well is the foundation for getting good results with ai.

And that's what our, that's what people are seeing when they're trying this out for quality management or RFPs or RFIs. What they're seeing is the hard parts are processing bad file formats, right? And import and export out of Word and PDF and stuff.

Or like you were saying, um, form filling, like being able to go headlessly and go to fill, you know, get a form and, uh, you know, ultimately fill it out with no human involved and make sure it's accurate and that, you know, all of that stuff. Um, those are all, you know, those are all tools, but like you were saying, for our, our customers, what their, what their ideal state would be, anytime any customer has anything that they need in any format, if they need docs, if they need a form filled out, if they need whatever, they can go to this system called conveyor, right? But their customer doesn't need to know that.

com or you know, Workday, the workday, uh, customer, um, you know, compliance portal or whatever they wanna call it. But they can go to the system and their customers either through, if they need like documents, they can get documents. But if they need anything with ai, it's gonna be secure.

Like, they're gonna authenticate to the ai, the AI will be able to talk, pull up their Salesforce record, just like talking with a human. We'll be able to say, Hey, gimme any form, any questions, anything you need filled out, and I'll be able to get it back to you in a few minutes here. Like, complete, complete automation of this kind of, yeah.

Like trust, trust building, not just around security. You know, today a lot of our marketing, like I said, is focused security, but what it really is, is anything that the business is gonna be making these kinds of representations too. So it in it includes helping automate RFP and RFI stuff.

You know, like I said, you know, companies that have promises to their customers that, you know, they ultimately get ended, it ends up being like compliance paperwork, right? Your customer sends you something and they say, Hey, you have to attest whether you comply. But like for, um, for some of these manufacturing companies, they're not making software and the questions aren't about digital security.

They're making precision manufacturing machines, or, uh, they're making potatoes or they're making logistics like freight, you know, shipping. And they are still, what they wanna be able to do is achieve that dream where they have a system, everything, all the knowledge is in the system, and then customers just get instantly, anytime, whenever they need it. Perfect.

Trust building. Perfect. You know, and that it's like not just a form filling, but anything they need, any answers, oh, one-off questions, like here, here you go, on demand instantly at scale.

That's the dream for them. And so ai, all the AI stuff and the various products, and we have a, uh, uh, agentic customer trust intake agent today, we're launching an RFP agent, uh, next week. Uh, you know, like all of that future is still just trying to serve the dream of perfect instant, you know, high quality trust building, you know, on tap anytime.

Love it. Ja. We're way over time.

Yeah. I gotta pull the plug on this one. No worries.

But hey, thanks for coming on here and, and getting us smart on conveyor. It's a gr look, this is a great story. They'll make a movie of it one day, but, um, you know, keep up the great work.

We'd love to hear you ki add agentic ai. 'cause look, that's still in itself fairly new, right? As this continues to develop, though, we'd love to have you back on and talk about how it's kind of taken you to the next level here, or allowing your customers to build trust with their customers.

Yeah. And as I, you know, we didn't even talk about this, but as you have not just one agent, but multiple agents, how do you oversee them? How do you manage them?

How do you deal with quality? How do you deal with region Orchestration, Errors and exception handling, you know, all of this. And yeah.

The ton of, a ton of really interesting stuff to go Into that. It's interesting times for sure, my friend. Yeah.

All right. All right. Chad Belu, C Chad Belu, CEO of conveyor Here on Techstrong tv.

We're gonna take a break. We'll be back with more. Hello and welcome to the Techstrong AI podcast.

I'm Amanda Ani. I'm excited to be here today with Greg Whalen. He is the CTO of Prove ai.

How are you doing today? I'm great, how are you? Thanks for having me.

Happy to have you on the show. Can you share a little bit about prove AI and then some of your experience? Yes, absolutely.

So, at Prove ai, our mission is to de-risk the development of ai, right? And specifically right now, we mean generative AI and LLMs, right? So the, the problem we're reacting to, um, you know, that we're hearing from customers, right?

Is that, um, there's a lot of organizations are just getting started with, with ai, right? Developments, they're starting to figure out, um, okay, they built something useful. Now let's start putting this into production, right?

Let's start using this thing, right? Like, like any other sort of software in the past, this raises questions, right? And, um, since AI is a very different animal, AI development is a different animal than traditional software.

What, what, what we're seeing is that the traditional approaches to risk management and to, by the, you know, the types of things you need to worry about when you deploy software are different, right? And they're starting to confuse people and, uh, right, they're starting to put on, you know, the breaks, right? So, prove ai, what we're, what our mission here is to say, let's not repeat the mistakes of the past, right?

So when computing paradigms have changed and we found out more productive ways or faster ways to develop software, right? Let's not make the same mistakes and, uh, just continue as ignore the problems, right? And then find out later on that, uh, oh, we're gonna have to redo everything, right?

We have to reinvestigate our approach to risk management, and this, that, right? Because it just slows everything down. People get annoyed, and, you know, those who are better prepared for it will leapfrog and be able to be the market leaders, right?

First in market. So, right. Our software is specifically designed to help customers through those types of, um, challenges by basically preparing themselves more long term for doing AI development, um, you know, at scale, which we think everybody's gonna have to do, um, given the importance of it.

Absolutely. And I imagine, you know, having to backtrack, not only is it a waste of time and energy, but probably a financial strain as well. Absolutely.

Absolutely. So, so yes, there's, there's immediate cost ROI here that comes down to time and productivity, right? So in addition to, to mitigating risks and things like that, right?

Even if you sort of say, well, we don't know what the risks are yet, because we're still so early in the journey Yeah. That that's true. But imagine the cost, the financial costs you're going to have by, by basically furloughing, you know, many developers for, and, and introducing processes that worked for cloud, you know, cloud development or web two development that don't particularly work well for AI development, right?

The costs are very big. By then, you'll have teams of people working on this, probably relatively highly compensated teams, right? And basically, by, by making it such that they can't spend every waking day developing software is lost money, right?

And, you know, we think that there's returns by investing in this now, so you never have to get into that state to begin with. So from your experience working with different clients, what are some of the biggest risks or problems that you've seen them encounter? And what advice do you have to avoid those risks?

Yeah, so think that, that the biggest, the biggest risk or the biggest, uh, you know, problem that we can solve at the high level, it's a business problem. It's not really a risk, it's, it's, it's understanding like, and communicating what our mutual obligations are between multiple departments or multiple, you know, parties. So it's the breakdown in communication between those multiple parties.

That's the biggest risk. So it's like, I, I say that for instance, let's take a very practical example around data assets and data usage, right? So me as a vendor, I have a solution.

It maybe it's a, maybe it's a great solution and, uh, maybe it uses, um, some sort of AI behind the scenes. Um, you know, and, and maybe I wanna be sure as somebody who buys the solution around what sort of data assets it's using, right behind the scenes. So I want assurance that every time that you change something, you're gonna guarantee to me that you're, you're, you're applying the same ethical standards, the same kind of legal standards that, that I need to make sure that I can keep using, you know, your software, because I don't know what sort of training data is actually being used behind the scenes for your solution, right?

So you have a very practical problem in the old world, right? We would've maybe just signed some sort of contract or something like that, that says, Hey, you're not gonna do thing X that I don't want you to do. Or you would, you would establish an SLA that establishes uptime and availability and error rates, and establishes what we're going to do when we breach those types of things.

Uh, the, the problem in today's world is that doesn't, the problem in the AI world is that doesn't work particularly well anymore, right? Even because the, the sense of what's, what's good and what's bad, or what, you know, what you can do, and what you can't do is so blurry that unless you're really in the details, right down to the level of exactly what data is being used, by whom, by where, where is the model running then, then the whole, the whole discussion around mutual obligations is pointless to begin with because it's, it's impossible to write in just standard right? Contractual terms anymore.

So, so like, you know, the, the biggest, like, problem number one is simply expressing, right, what we actually expect of each other. And, um, for proof ai, right? We do this in the form of modules, software modules, right?

That allow you to concisely and clearly in, in code, of course, right? So this is this, it still has to be translated to code. Like, you know, let's get into the details of your data sets, which detail, which data sets are we talking about?

Which models are we talking about specifically who owns them, right? And now let's, let's track the events from those particular, you know, from the systems that manage those. And let's, let's talk about and define what's good and what's bad, right?

What's acceptable, what's not acceptable. And when things start to go unacceptable, I wanna be notified in real time as a customer that, hey, we're in a potential breach so that we don't have to have a big complicated, you know, discussion about it, right? Did we or did we not?

Right? It's, it's simply a, this was the model we were talking about. These were the data sets we were talking about.

This is what we said we would do on update. Are we doing those things? Are we not?

Right? It's a much more practical discussion, right, to have than than others. So I'll answer it that way, right?

I think the biggest discussion is there, there's sort of this fear of, okay, I wanna use this solution, but I really have no idea what it's doing behind the scenes. And then, okay, I I, I want to address that problem, right? I wanna have a discussion about it, but the discussion is unruly because it's so difficult to be specific, right?

And, and, and, um, you know, that's actually the, the first problem that we think is gonnas we'd like to solve, because that's what gets in the way of, of doing anything right now. It's just, uh, you know, I'm, I'm a customer, I'm worried I want assurances. Um, I know what assurances I want at a high level.

I don't know how to define it and I don't know how to track it. So, you know, you can start there. That's one of the first, you know, problems to, you know, to start with.

Absolutely. And so, I know there's a lot of, um, new regulations and AI laws, uh, in fact a few introduced by the eu. Uh, how do companies need to, um, address and, and, um, adhere to these new laws and regulations and stay on top of those?

Yep. Yep. So, um, we think that at least my, my personal take is somebody with a technical background here, right?

So I don't have a compliance background, right? But, but of course, over the, the past many decades, right? Have, having been through many compliance waves, right?

I think that the best way to stay on top of things is to, you know, approach these things. As you know, compliance is basically the bare minimum, right? So, like, whatever's going on in compliance is very, very much worth your time to look at today, right?

Figure out, hey, you know, if, if I had to comply with this tomorrow, could I, because even if you don't, it's still a very good thought exercise, right? Around where would I have to start? Because generally, compliances are not, they, you know, they don't fully me tell you how to manage risk in your organization, right?

They're very much a sort of baseline standard about, Hey, let's be sensible. You should at least be doing these things, right? So in general, my my take is that you, you don't wanna be caught sideways in another year when you find out you have to comply with something, right?

That's the, that's the way that people have often, you know, said, oh, we don't need to worry about that IO standard yet, because it's not a law, right? So let's just wait. Um, okay.

But then when something does happen, even if it's not io, it's something similar to an IO standard, and then you probably could have been, you probably would've saved yourself a lot of pain if you had just said, yeah, let's, let's read the standard and let's, let's make sure we could roughly comply with it now, because that's gonna probably be a pretty good, you know, framework and platform to start with, to actually manage risk in my ai. So you, in summary, I, I think it's a, regardless of when they're going to become required, or whether they're considered sufficient to transmit to other parties that, Hey, I'm doing what's, what's legally required, even if that never happens, the point is, a lot of people started and put a, and a lot of smart people put a lot of thought into the AI ISO standards that really it's worth looking at and saying, maybe I should just start there, and maybe that's a good, you know, starting place. And then let's build on it to figure out like, what do I have to do extra to really manage, you know, risk of AI development, either with my partners or internally.

So still very much recommended that you start, you know, looking at it as a baseline just because, you know, where else are you going to get an, you know, an output from many people who are very experienced in the, you know, in the field telling you that, Hey, this is probably a pretty common thing everybody should be doing, right? It's, it's, it's worth doing now so you're not caught unaware in another year. Right?

And, you know, even if it's not law, somebody's gonna ask you those same questions because they're very much a baseline, right? None of these things are outlandish, crazy things to do. They're, they're, they're very much a, a, a, a bare minimum in many cases, right?

So why not, why not start? Now? I understand many business leaders have concern with budgets when it comes to integrating new AI tools, uh, to solve problems, and they're looking for that return on investment.

So what advice do you have for them? Yeah. Do, do, I guess, would you mean for like a compliance tool or actually just for an investment in ai, It, um, investment in AI or compliance tools?

Um, I'd like your opinion on it. Sure, Sure. So for, I mean, I, I think most of the investment, we, at least from a compliance tool, right?

We wanna see that the investment is tied to the actual solution, right? So, right. That they believe enough in AI that in their AI project, that they know exactly what they're going to, you know, get out of it.

So, like, if you're in, if it's a, if it's a relatively common customer support use case, right? We're talking about having a very clear idea that, you know, we want, you know, you know, we wanna automate ticket response, we wanna see, you know, customer happiness increase, we wanna see throughput, and we ultimately want to lower, you know, cost of, um, you know, cost of, you know, cost of serving cost, right? The cost to serve the customers.

Um, I mean, that would be an example. So I, I don't, so I mean, the recommendation would be that, you know, rather than thinking about investment in compliance is separate, I think it's, it's absolutely necessary to just think about what is the actual, you know, return on this, on the AI thing that you're, the ai, ai embedded product that you're working on. Um, so it's gonna vary wildly by, uh, by use case, right?

Customer support is usually error rates decrease, right? Customer, uh, you know, time to serve customers drops, right? Which is good, right?

And the error rates, error rates lower and overall lower labor costs, right? Decrease. Um, you know, for other things, let's take, you know, the ad tech space, right?

And targeting, right? Hey, targeting, you know, microsegmentation gets even more precise, right? You get to, you know, basically, you know, the, the revenue per customer, rev revenue per person serves, right?

Can increase in things like that, right? So it, it varies wildly, right? But, but usually you're talking about in all of these cases, right?

Doing something more quickly than a human being could do. So typically when you're talking about AI, is you're talking about doing a task that was traditionally assigned to a human right, was relatively slow, was a relatively, you know, large pain point, right? And now you're going to eliminate that sort of manual review, uh, you know, not because the human was slow, it just wasn't a task that was, that was scalable towards, you know, towards, um, you know, a human line of thought.

So we're saying, you know, we got software up to a point where it was automated, there was a manual check, typically, typically an AI of some sort is replacing, you know, what used to fall back on people, right? So you can imagine the savings is always, you know, better accuracy, you know, at lower cost. Um, so what, you know, then the return though of a compliance tool like us is to say, okay, but, but, you know, there's a hidden cost here, right?

So I think that's our, that's our big cautionary tale here to people deploying ai, is that, um, okay, yes, you're gonna save this money if this AI performs well, unlike a human, right? AI don't always have, or AI agents or, or whatever, they don't always have, you know, common sense, what we perceive as common sense, right? Which means that, you know, you, you might have a very anomalous, unexpected error that has a huge blast radius, right?

That's just like, whoa, like a human would've never made this error. So the AI may be like, wow, this thing is, is awesome. It really does in fact, perform better than human review.

It does a lot faster. But you're going to find these unexpected untestable, undiscoverable, you know, kind of, um, you know, instances where there's just a big problem. It's a high cost, right?

High brand damage, right? It could be a, it could be something as saying, you know, of, of a, a poor refund handling or something like that, where, hey, there's an exploit and, and suddenly your automated solution is starting to give out refunds that really would never have ever happened under human review, right? So there's monetary loss as well.

And we've, we've seen actually, you know, some of these things have actually already happened. Um, you know, so, so we say, okay, well then the return on investment of a compliance tool or of a risk management tool de-risking AI, is to say, yeah, those things are going to happen, right? And right, we're going to prove return on our investment by saying that when they happen, the blast radius is going to be as minimal as possible.

The the downtime is gonna be as minimal as possible, and this is gonna be traceable, right? It's gonna be very clear who messed up, right? So a lot of companies don't have that today.

It's gonna be a discussion when something happens and it will happen. Uh, it's going to be unexpectedly large in some cases, right? The impact is gonna be, whoa, you know, how did that happen?

Uh, that's very damaging. And then it's gonna be who's at fault, right? How do we fix it?

Right? What actually happened and who's at fault? Um, without having something in place that actually tracked every single thing, every single prediction, and every single stage in the development across multiple organizations, right?

Multiple data sets, multiple parties, then you're never gonna be able to get to the bottom of that question, right? It's gonna be a finger pointing match, it's going to be a, well, we need a couple of weeks to dig into the logs and then share logs with each other, right? Which is a very traditional software development process, right?

There was an outage. I want a root cause analysis. I want an action list of what's you know, of, of how to, how this, uh, how we can never repeat this again.

It's not gonna work very well with an AI model, because there, there's no specific list of actions, right? Other than we need to review things manually that you're gonna come up with. And we've already said earlier that that's the wrong approach, right?

Because that doesn't scale either. So, right? That's what we think the return is.

The the return here is, um, it's very much around managing those, those sort of big blast radius anomalies that are inevitable, you know, going to come up and then reducing the amount of time to resolution, reducing the amount of time and effort spent figuring out who did what, right? And then figuring out how we never happen again at a precise level, right? Where in the chain did this actually fail?

So a very helpful tool to have, especially as we see AI being utilized for so many more things and so many more automations. Absolutely. Yes.

All right. Well, if there was one key takeaway you could leave our audience with today, what would that be? Yeah, so going back to the beginning, I think key takeaway, I think is to get started with, you know, de-risking now, right?

So obviously that's a bit self-serving as you can imagine, but I think it's, uh, it's been the right advice, you know, to customers over the many waves of computing, right? It's, it's, as we started to do cloud development as we did web development, right? Getting, getting ahead of it is going to save your developers and your organization a massive headache by doing just a little bit now so that you're prepared when inevitably a customer asks for something, right?

They say, all right, we have, we need to have a risk discussion, right? Or a regulation is imposed and you have to go react to it. So, you know, the, the the, you know, the recommendation here is you're gonna need to move fast, right?

Don't wait. Um, thinking about compliance and risk is actually pretty healthy for an organization now because it allows you to move faster, right? You don't have confusing discussions with leaders and pe right?

It forces them to start to get educated now, which is actually better, right? So to your earlier question about return on investment, right? It's, it's probably net positive, right?

Even if you don't have a lot of AI now, because it, at least it brings everybody to the table to talk in a data-driven way about risks and about specifics of a model, partic, you know, potential pitfalls, right? In a way that really we've seen a lot of customers have challenges with. Alright, well thank you so much for coming on the show and sharing your insights with us today.

Uh, Thank you for your time. I appreciate it. And thank you to our audience.

Stay tuned. There's more. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com. Home of security bloggers network. Hey everyone, I'm Alan Shiel.

That's Luca gte and you are watching the Platform Engineering Show. Hey, Luca, happy New Year. It's great to see you, my friend.

How are you? You too. I'm good.

How are you doing? Happy New Year. Happy year everybody.

Yeah. Happy New Year to everyone. So, Luca, where let's play.

Where's Luca? Where in the world are you today? Man, east coast Is Sri Lanka, The east coast of Sri Lanka.

That's great. And it's nice and warm there. You're on the beach.

Yeah, I freezing apparently tour that in Florida, right? Yeah, well, winter, winter came to Florida, right? But we get this around this time of year, we'll get like three, four days.

I was telling you where it, sometimes it'll go down even into the high thirties, low forties, fa night. And then the, the, uh, the iguanas that are, they're not native, but they're invasive here. They, they get frozen up in the palm trees and they go what they call topi, like, you know, they just shut down and then they fall outta trees.

And some of these I gus are like four feet tall. I mean, they're big, they're big reptiles, so you don't want 'em falling on your head. Y'all get hurt.

But, uh, this is so Fascinating to me. It's crazy. It is crazy.

But, but, but do they recover or are they dead? Um, it depends how long and how cold they are. How long, because, you know, with Gus are usually like that nice green color, and then when they're in reading colors, they get red and orange.

When they get topi like that, they turned gray. It's like they really Yeah, it's a good dark. They look like off.

Yeah. Um, crazy. But yeah, we'll see.

I mean, no, they're, they're kind of like a nuisance animal here. So people aren't terribly upset that some iguanas die. Uh, they don't belong here and they just, they're a mess.

They're a mess. Right. Anyway, enough about iguanas.

You're in Sri Lanka. There's a lot going on in the world of platform engineering, though. We got a great topic to cover today.

But before we do, I wanted to just go over with you a few things. First of all, we're making plans here to head over to London for Cube Con. I think it's April 1st to the fourth is the actual cube con.

Um, but I know the community has, has some real big plans going on. You wanna share a Little? Yeah, it's gonna be, it's gonna be a big one.

Um, cube Con, right? In London, they're expecting 12,000 people. And so we do our sort of like unofficial cube con opening party, which is Coha Cube.

We've been doing it now for like two or three years. It grows every time, expecting a lot of people. Probably like 4,000 plus signups.

There's probably gonna be like 500 people, 600 people at the location. It'll be pretty crazy. And, and you know, the whole thing, us cubes, like we started it when I think we were at CubeCon Valencia, and it was basically, oh, I love that.

We Were kind of going from like, which was great 'cause it was like Valencia and so on, but we were basically going from like one party to the next, or like, man, all these parties are the same. Um, and obviously, you know, we have like a Berlin background, uh, techno background. So we were kind of like, wouldn't it be funny to do the sort of like, uh, the dark room of DevOps?

Um, and for those that catch the reference. Um, and, and, and so it started like as, as a joke, but we did it. Um, and it's really funny 'cause it's always, there's a bit of, bit of a tension with the CNCF guidelines that basically don't allow you to stay in the dark room of DevOps.

Um, but yeah, so we started and, and, and now it grew to basically really become the unofficial opening party. You know, we have like drag queen shows and it's a whole thing. So, so that's gonna be really fun.

Really. Oh, Very cool. Um, yeah, yeah, yeah.

Looking forward to that one. Kind of Like Key West Yeah. Down here.

We, that's, I dunno if you've ever been down to Key West, but they lot of that No, but I heard, yeah. Um, Yeah, Yeah, it is. Yeah.

Well there are other places that are more, but anyway, um, I digress. Let, where can people get more information about House A Cube? com, um, and you could sign up.

It's free. We have, uh, amazing Food, amazing drinks, amazing Drive, Queens. So just count for fun.

Most party, We're gonna do that. That's fun. That sounds great.

And then the other, you know, big thing on the horizon, and it's not too early to get this out there, is, this is the third or fourth platform con This is coming Up in June, this fourth platform con So we started 22. Yeah, that's right. Um, we had like, I think like 6,000 people or so joining virtually.

Um, then we had Popcorn Con 23, we had like 20,000 at 24 last year we had like 35,000 or something, and then expecting like over 40,000, um, this year. But the important thing this year is that we're really doubling down on the in-person components. So we're gonna have two live days.

One in London, one in New York, both around like four or 500 people. Um, you know, we have great speakers, Nikki wa Gregor Hope at Kelsey Hightower speaking at this things live. So really excited about that.

It's gonna be last week of June. So London on the 25th of June. And, uh, New York on the 26th of June.

Uh, so it's gonna be fun to like hop between one city and the next. Um, but the, I think the events are gonna be great. We're gonna have parties.

We, we have like a lot of great like, speakers live trainings, a lot of new formats that we're rolling out for this. com. Um, and you can choose your, uh, choose your own adventure, uh, and join us either virtually or in person London and New York.

I think Textron TV will be in New York. I'd love to come home to New York. Um, and we'll be broadcasting live from there as well.

Yes. So it should be a fun, fun, fun thing. com.

Yeah. Right. Fantastic.

Uh, speakers are, uh, all speakers have been assigned. What about sponsorships available? Yeah, sponsorship still available.

Um, almost sold out of New York. Um, that, that's gone pretty quickly. Um, and, and you know, we're closed with London, but there's still, there's, there's a lot of like, you know, um, so like also virtual sponsorships are still open.

Sure. Um, so anyway, sponsorship, sponsorship's still open. Um, and there's a lot of like, interesting formats that, as I said, we rolled out the trainings, but also, you know, we're gonna do live interviews with you in New York, for example.

So lots of new interesting things that I think can be very fun as well to do with, uh, with vendors and other sponsors. Very cool. Very cool.

Alright, Luca, we gotta talk about what we're talking about. You know, this is, uh, our third episode. Yep.

This is our third episode. This will probably be the last one where it's just you and I talk in like this. Well, we gotta bring in some fresh blood, some expertise, and, you know, we'll announce, uh, check marks is gonna sponsor our show.

So many thanks to them for that. We're looking at other sponsors if, if anyone out there might be interested. Um, but for today, Luca, we're gonna talk about platform as a product.

And look in today's world, right, there's platform as a product because everything is as a service, right? So here we got PAAP, and I'm sure the next thing will be PAAS, but you know, what does it actually mean when we talk about platform as a product? And, you know, it's a, it's a key part of this platform engineering kind of mindset.

But, you know, you're the expert. Why don't you define it? Yeah, absolutely.

And, and I actually think it's a good place to start from the PAAS that you mentioned, right? So like the, the platform as a service, right? This is just, is kind of like, uh, one of sort of the, the main trends.

If you look back like 15, 20 years ago and like Heroku, all those guys, Heroku star. Yeah. And yeah, and, and, and, and it was just said yeah.

Of like, Hey, like don't worry about anything, right? Like, we, we build this like platform layer for you. It's, you know, it's like turnkey, plug and play, let's go.

Um, and, and that didn't really scale to the enterprise, right? Because like everybody realized, hey, you actually need, um, you know, some, some customized platform layer, uh, for your, for your own enterprise engineer organization. And, and that's kind of what platform engineering, sort of like, you know, where we're sort of like platform, platform as a service or pass ends and, and sort of like platform engineering starts is really this idea of like, hey, you're building this internal product or internal consumption, right?

Like your internal customers are the, um, the, your, your application developers. Uh, and you do that as a product, right? And that's like a very, um, it's probably in my opinion, the key concept.

Um, the key foundational concept of platform engineering and also the key differentiator, um, you know, of platform engineers vis-a-vis, let's say like a doubts engineer or, you know, an SRE, um, that, that normally we'd approach infrastructure project as a kind of like one and done, you know, six months project, something of that kind. Whereas a platform engineer, at least like a, like a good one, um, approaches building an internal developer platform or IDP, which is the end product of a platform engineering initiative as a product, right? So a product that has a life cycle, not that it's, so it's not like a one and done, you know, six months thing, but it's actually, it's being rolled out as a minimal rev viable platform initially, um, for the first few months and then irate on, and then eventually grows.

Um, it gets adopted widely across the engineer organization. Um, right? And, and it keeps being worked on as a product.

Uh, and I think it's, it's a, it's a super interesting concept because the moment you look at your internal developer platform as a product, you immediately unlock, you know, 20, 30 years of product management best practices and experience that that we have in the industry that can be applied to build, uh, your terms valve often as a product, Right? And, and here's the thing, whenever you talk about something as a product, the next logical conclusion is who's the customer, right? And, and traditionally that was in it, right?

In the IT department going back, I'm going back now, you know, 25, 30 years. The IT department, the, the customer was the internal business, right? It wasn't sort of forward external facing, it was internal, right?

Basic. Right? Right.

And and your customer was the, was the sales guy, the business guy, the marketing person, the HR department, you know, all, all of the above IT service them. It, you know, they, they were the customer of the IT department. So this, I mean, this is not new in terms of a concept of of of that internal customer that gets served, you know, uh, in this case with, with the platform.

The other thing I'll tell you is, look, you know, when, when cloud first came out, a lot of people were very definitive about saying, well, this is infrastructure as a service, IAS, right? And we're gonna have platform as a service, right? And, and haruku was probably the biggest success coming out of that.

But really to a lot of people that meant, well, infrastructure service ended at kind of the hypervisor. They took care of everything hypervisor and below, and you built on top of the hypervisor os and everything else in IT platform as a service initially to a lot of people was, well, no, everything up through the os. And then you just build your app on top of the os.

And I'll tell you my 2 cents on it, if it wasn't for platform as a service not being sort of a complete, uh, concept, you never would've had cloud native. I think what we see as cloud native today with the containers and, and cobe and mesh and everything, you know, that old cloud native stack is a better platform as a service, or it's a result of the initial like Heroku style platform as a service just not being complete enough, right? It wasn't what we need.

And then, so now you got this cloud native stack, and now you have this whole platform engineering kinda movement, right? Which is borrowing from a lot of what, what's gone on here. And that's the modern platform as a product platform, as a service that I think people were really thinking about back when, but the initial like Haruku versions were, I don't wanna say flawed, but incomplete.

They were immature, right? Yeah. And, and so I, I think there, there, mm-hmm.

There were like a child Of, no, that's my 2 cents Of the, the, of its time, right? O of like, yeah. Also, like I think stacks that were like a lot simpler, right?

Infrastructure mm-hmm. That were a lot simpler. And, and, but then to your point, right, as cloud native exploded, as the, like, complexity really, um, really exploded as well, then you have to have like a completely different approach.

So it's like the idea is, hey, I still wanna provide a, a path like experience to my developers, right? Um, and, and, and, and I think like your, your, uh, priority is super interesting, right? Like, it's also not only the complexity of the infrastructure exploded, but also the, uh, size of the engineering organization exploded to the point where now you have a part of the engineering organization, the serving the other part of the engineering organization as, as its internal customers and no longer just like the sales, marketing, hr, whatever, right?

The other functions. And so, and that is also like a, there's also like a, like a mind mindset shift that that needs to happen a lot of times where it's like, well actually the internal customers is the developer itself, right? Um, which is something that a lot of people are not used to because they think, well, developers kind of build stuff for themselves.

Well, but the, the problem is like, once you have, you know, 10,000 developers and you actually need somebody that like specifically builds stuff for them, right? So, um, but yeah, so the idea is really like, hey, I want to build a task like experience for developers, but on top of, you know, a complex and changing and, and, you know, cloud native or hybrid tool chain. Um, and so therefore I, you know, I, I I need to take, you know, the, the vision is the same.

I take the tool set, um, you know, in the toolbox of, you know, I borrow it from, from, from kind of like all this other like adjacent disciplines. Um, and then really, like, I focus with this like, product mindset on, on building this site. Um, so like platform layer developer, um, DevX, uh, layer on top of this increasingly complex, uh, stack.

Right? Absolutely. Hey, you mentioned DevX.

I just wanna give a quick shout out. We're gonna do our first live round table of the platform engineering show, um, I think early in February. And it's on DevX.

So if DevX is something you guys are interested and your folks are interested in, uh, stay tuned. We've got a live one where you can take part and ask questions, and we're gonna dive into that. Now, Luca, the, the platform is a product idea.

You know, it's been percolating now for a couple of years, and we're starting to see, I don't know if I want to call it best practices yet, or, you know, evolving best practices. I don't know if it's written in stone everything just yet, but we're starting to certainly see where, hey, this works. This is not such a good idea.

There's a better way of doing that, you know, we're evolving best practices. Can you talk a little bit about what some of these are and, and where people can kind of, you know, stay in the know on that? Yeah, absolutely.

I think like, um, you know, and, and as I mentioned, like, I think what's interesting is the moment you treat your pop your internal product, your internal platform as a product, you unlock all this like best practice. Like, so it's not like you need to invent anything radically new. It's like, hey, there is this minimum viable product MVP concept, it's just being rebranded to mini level platform, which is the same exact letters, and the concept is the same.

It's like, hey, start small, irate quickly, and so on. Um, I'll cover, I'll, I'll talk about MVP in a second. The, but, but I think like before that even, um, like if we look, I think chronologically, and I've seen the, the space sort of like mature in the last couple of years.

You know, initially it was kind of like, okay, like what is platform engineering? Is this helpful for me now? It's like a lot of people are like really bought in to the concept.

Like it's been, you know, compound like crazy. And we spoke about the, you know, the overall like, you know, numbers about platform engineering as a trend broadly in the other episodes. Um, but you know, with that, a lot of people are coming in, they're like, okay, you know, I'm bought in.

I heard this is cool. Where do I start? Right?

Like, what does this thing actually look like and how do I make sense of this? You know? Yes, we have like a, like a crazy, like cloud native, and so landscape, you can just see the CCF landscape is insane.

Like nobody can actually really understand it, but, um, but even the platform engineer, it makes a good picture. It makes very good picture. Exactly.

Um, and, and, but even the possible engineering landscape at this point has been developing so much that, you know, it's far from that level of complexity. But you know, you already have, like, if you're a newcomer in, and it's like, okay, like how do I, you know, how do I actually piece all this, this from, you know, pieces of the puzzle together for a platform that actually works for me that makes sense for my engineering organization, right? And so that's where I think the first sort of like standard that's been really, really helpful in a game changer.

I think in the, in the community and, and, and broadly in the platform engineering market has been this, this reference architecture is for interior developer platforms, right? Um, and, and some of the first ones were, um, open source, uh, by McKinsey actually. Um, and then, you know, kind of like, now they're like really widely adopted.

Um, I have one stat for you on that, which is recon. Um, they were, so the first, the first, uh, reference architecture was, uh, uh, was kind of like presented in the talk at, at recon 23. Um, and so there was only one at Platform Con 24 last year.

There were already like 20, 30% of the talks that were using, um, this as a blueprint to kind of like talk through, uh, the platform that practitioners built or whatever, right? So very, very interesting to see like how quickly people adopted this. And it's for a very good reason.

It's just like, it gives like a really good guidance as to like, okay, how do we see, how do you think about the different pieces and how to fit together? org, I think slash tooling or slash platform tooling is, um, you can see the sort of the tooling landscape there. And that also follows the same structure, um, as the, as the reference architecture.

So that was kinda like a first step that was really helpful. But then sort of like, what I've noticed is that people were, um, kind of like looking at this and like, okay, great, that's, that's my target setup. Like, that's how I want to build my platform.

Um, but then they were trying to do everything, you know, at once, um, like, you know, the, the, the Korean movie, like everything everywhere, all at once. It's kind of like, it's kind of like, like that, right? Like they were trying to like, okay, like this is great, you know, they get super excited, you know, I get buy in some executives, let's go, you know, build everything, right?

And the problem with that is that, you know, you very, very easily lose momentum, right? And this is, I think, in my opinion, is the number one cause of death apart from engineering initiatives, uh, to be a bit morbid, but it's, um, it's really, it's really like that, right? Like it's, it's people that get really excited that have this like brand designs, um, for, for what the platform is gonna look like.

And the problem is that the platform engineer really is a huge, you know, org transformation, right? And so, uh, and so that means it touches all these different stakeholders, application developers, executives, architects, security teams, infrastructure and operations teams. And so you need to basically get all these people on board with you, you know, sell them effectively internally, this idea of the platform and it's different components that you have like so beautifully designed in your head.

Um, and, and so the problem is like, it's very easy to lose momentum there, right? Because you need, you know, by the time you, you know, you spoke to person A, B, C by the time you, you spoke to person Z, it's been six months person a completely forgot about you, and, you know, you kind of get stuck in this process, right? And, and there the trick is really to take this minimum viable product or minimum viable platform approach of saying, Hey, start small.

Um, focus on like a really, like a subset of, um, uh, not only the problem that you're solving for, for different stakeholders, but actually a, a a subset of the stakeholders, right? So just focus on, on maybe like application developers and security teams or, you know, infrastructure, infrastructure and operations team and executives. Really, you don't have to please everybody immediately just focus on like, what's the low hanging fruit here?

And then if you think about that ference architecture that maybe we can link in the, in the show notes or like throw up a picture at some point, um, we can, you know, you can, you can, you can think of like, well, let's, let's actually focus on a subset of events, right? You don't need, you know, your MVP to have a full, um, you know, to be fully security compliant, uh, or, you know, have, uh, you know, the, the latest observability stack built in already. 'cause you, you're not going to production right away with this thing, right?

You need to first show the value to, for example, developers and say, Hey, look, you know, Jimmy right now is spending, um, you know, like, um, uh, is, is is waiting like two weeks every time, uh, he wants, he needs a database, right? Um, and, um, you know, and is providing that. Um, but you know, now she's like fielding this like oldest like ticket request, but like 40% of her time and that sucks, right?

And so what you want in the first MVP is, is to actually show, okay, well I, you know, I, I proved, uh, you know, for example, I reduced the, the, the time that Jimmy needs out for database from like weeks to minutes. And now Amy only needs to spend like 10 minutes, 10, you know, 10% of her time fielding ticket request, not like 40, 50%, right? Like, and you know, and, and you can, you can show that within weeks, right?

That's really the powerful thing I've seen, um, like very large enterprises move incredibly fast following this MVP framework, um, and within weeks show some level of success internally to the, the stakeholders they selected. And then from there it's like, okay, great. Are we all happy?

Yes. Okay, let's go to the next iteration, right? And then of course, you should have, like, you should design the end design with, you know, security in mind, for example.

But it doesn't mean you need to implement all the latest governance and security workflows from the get go. 'cause this is gonna slow you down and not gonna get you to actually show value. So, um, I think reference architectures and MVP framework have been, um, very, um, very helpful standards and very helpful best practices that, as I said, you know, we've been borrowing from existing, existing disciplines already, um, and just like slightly tweaked, uh, to, uh, to really help platform teams deliver on their, on their initiatives.

Excellent. Excellent. I mean, Luca, if I, if I had a boiler, it's a bad word to use, Casson Lee used that word.

If I had to like, just really give people in one line here, right? You, you, you don't wanna boil the ocean with platform as a product you want, you, I you want to do it step by step bit by bit. Here's my question for you though.

Do you need a master plan to begin with saying, okay, here's I, here's step one through six, it may take me three months to do step one, four months to do step two, four months later I'll do step three, but eventually I'll get to steps all the way through to step six. Or do you just say, well, let's start with step one and then I'll decide what even step two is because I don't know if I want to make that right. What I'm labeling now as step three may wind up being step two.

Um, right. So I'm not, I'm not locking into any of that. I'm just locking into step one right now.

Totally. I think it, I think it, um, I think it's a mix of both, to be honest. org actually has like different tracks.

Like you have an executive track or business track, you have like a technical track, which is basically, you know, how you build everything, how you get the first like developer adoption, you have a security track, how do you make the security team happy, right? And I think like different tracks have different timelines and you need to, right? So like I think for security and business for example, it is helpful to have a little bit of, you know, like a look into the future, right?

Um, and like how do you attach, because you know, for example, like your business, your business stakeholders, like your execs, like, you know, usually sinking quarters or even like fiscal years, right? So like how do you attach, you know, your engineer initiative to whatever their goal is, for example, for, uh, you know, for the quarter, for the year, um, in some cases multi-year plans, right? Um, on the developer adoption though, on the other hand, like, it's really what you were saying, um, it, it, it doesn't make sense to just get started, just get started, figure out, you know, what works, what doesn't, and then I from there, right?

So, um, I think there's a combination, and this is also I think where it's helpful to think of your platform as a product. You know, you know, we've built product, um, uh, products and, you know, the product is not just about building a product, it's also going to market with that product, right? So, um, and so that's where you have, you know, I think you have basically your product engineering teams atating very quickly on building a product, especially at the beginning, right?

And then as your platform matures, you can have like longer plans and like longer iteration cycles and so on, but at the beginning you want to be very nimble, right? Um, um, and the same thing kind of like goes for your go-to market at the beginning, you really need to figure out, okay, you know, which executive is gonna support my initiative and so on. But then like over time as it matures, you know, really like attach it to like, you know, very specific budgets or combination of budgets and so on, right?

Um, but it, I think it's, it's helpful to, to to, to not only think of like platform as a product, as something that's like purely technical in terms of like, like how do I drive developer adoption and how do I, um, you know, you know, iterate reviews from a product perspective, but really broadly, like if you consider it as a product, it means like it actually needs like its own go-to market, uh, its own internal marketing and internal sales effectively. Um, and actually you can see this, I was, I was talking a, a while back to Aaron Ericson, who's the guy that, that built the, the, the turn developer platform at Salesforce five years plus ago. And you know, it's very interesting because, because Salesforce is so big, actually at the time, they had multiple platform initiatives sort like bubbling up and competing with one another.

And so there you have even, and obviously like in, in most organizations you wouldn't have that, right? Um, but Salesforce, because they're so big, um, but there's some cases of like very large engineering orgs that have, um, similar situations. Um, and, and in that case, really you're competing, right?

And you're competing on the product front, but you're also competing on like distribution On the platform. Yeah. Yeah.

But I mean, look, you see that in large enterprises that are built through m and a, right? com days, right? We had 30 different acquisitions and each one had their own, you know, not platform per se, but their own it, their own, they were all, they were all storing websites, they were all website hosts.

So there was 30 different platforms to coast websites on how do you pick one or eventually you do want to get to one, but it took a really long time because you, you can't, you know, you're gonna wind up breaking some eggs, making that omelet and, and, and, and so you, there's a, there's an art to that, right? That's, that's a whole thing in and of itself. And, And, and how did you, how did you think about that?

Like how were you Well, we went bankrupt. Like I, well, what we, I mean we, well, because the do coms bubble, that's, yeah, that made it easy. I left, but no, but seriously, what we did do is we, we brought in, we, we developed one engineering team across all 30 acquisitions, one engineering team, and they basically took from each of the acquisitions what was best about them, what was the strengths, and then also looked at the wider state of art, right?

In the industry. And, and, and we did, we, we actually built a whole new platform that we migrated these two. Some, some were easy migrations, some were a lot harder migrations, but we built a state-of-the-art.

'cause back then, look, we, we had some companies that were using what I call baker racks, like that you would keep bread on and they would keep white label servers on there. The hard drives are in the server. The servers running Apache and they got a thousand websites on there, right?

Then we had other ones that were running like one new web servers to network attached storage, right? A very different kind of architecture. And we had other ones that, you know, had, would load balancers and you know, there was, there was a variety of, of, of architecture here.

And, and we settled on one and it took, it took the better part of a year and a half, two years to really migrate into the standard. The company was called inter reliant into the standard inter reliant architecture, which, which by the way back then was like IBM Domino server or something like that. And, you know, it was, it was big enterprise level stuff.

We were hosting a lot of apps. It was before there was cloud, you know, multi-tenants and all that. And we're hosting Oracle apps and Lotus Notes and, and Exchange and PeopleSoft and, you know, crazy stuff in addition to websites.

So we needed, and that's actually how I got into security. Then we had Layer Security in Checkpoint at the time. Was it, you know, checkpoint was the big firewall, right?

So we had managed checkpoint firewalls in front of this stuff. It was, it was really cool. 'cause we were way before our time, way, way, way before our time, right?

Um, but it was, it wasn't anything like, we didn't have at our fingertips what, you know, platform teams have today, right? We were inventing this stuff outta rock and chisels, you know, you didn't, you didn't have the tools we have today, but it was interesting. It was interesting.

That's so interesting. That's so interesting. And actually it's something that like, we are seeing a lot in the community as well.

Like we do this, uh, this trainings with large enterprises, um, where we kind of like help them either educating their teams or actually like putting together strategy for the rollouts and, you know, phase rollouts and so on. And I was actually working with like, um, okay, I think it's public right now, but anyway, it's like a very large, maybe the largest I think CPG merger ever. Um, and you know, it, it's kind of like you have these two teams and they, they sort of like are gonna go in, right?

It in, in gonna end up in the same setup. And, and so like one of them wants to figure out, okay, what's the right strategy for me going into this, right? Because I have like something that's working right now, but obviously everything is gonna change.

So like how do I, how do I make sure that my platform evolves in a way that it ends up being the winning popper, right? Uh, from an evolutionary perspective, it's the one actually surviving in the end. So very interesting.

These sort of like m and a conversations where you really see this like, yeah, like internal products competing with one another. Yeah. You also see personalities competing with one another, right?

And that, and that's sometimes the personalities are harder than the technologies, right? And, and, uh, that's a whole nother story we could talk over beers one day about. Anyway, uh, Luca This's been a fascinating discussion, man.

I loved it. Um, Yeah, this is fun. org, we've got reference architectures, we've got tools and people and documents out there to help people as we go on, as they set, you know, set sail on this journey of, of, you know, adopting platform as a product.

Um, wow, what a great show this was. Let, let's can't wait for the next one. Next one.

We'll have some people joining us, so it'll be more of a active discussion, but we hope you enjoyed this. Luca, how long are you in Sri Lanka? Uh, three more weeks.

Yes. Um, All right, so maybe for the next show, you'll still be there. Um, no, no, no.

The next show is in February, so we're gonna Okay. It'll be, uh, yeah, because these are almost mid-January, so where, where do you think in the world you might be by then? Japan, maybe.

I'm, you know what, there's a cube con in Japan in June. I was really had my eyes on, but we'll see. Yeah, it's a small one.

It's only two days, but, uh, okay, you going check it out, it, I might, I might. I'm looking for an excuse to go to Japan, so All right. Yeah, Yeah, yeah, Yeah.

We'll see how that goes. I'll let you know. Yeah.

Anyway, though, until then, enjoy Sri Laka. We hope you've enjoyed our, the platform engineering show. It is out episode three.

If you haven't caught the first two, you can, they're available on your favorite podcast platforms like Apple and Spotify and all of that. Also on text Drunk tv, and, and they, uh, text trunk TV is the website. They're also on the YouTube text trunk tv, YouTube, and I think by the, well, hopefully by the next show our Textron TV OTT channel will be up, so you'll be able to catch it on Apple TV and Roku and Amazon Fire as well as mobile apps.

But until then, is Alan Shimo Luca gte. I hope you've enjoyed the show. Take care everyone.

Thank you, Alan. Bye bye-Bye. Thank you everybody.

What's the role of executives in leading large software organization? That's not an easy answer for a couple reasons. First, software's different.

And second, it depends on if small teams can work independently or lots of team needs to work together to coordinate work. So why is software different? Well, it's helpful to understand the history of software to really appreciate that, and Jim Highsmith's done a great job of documenting 60 years of history of software management approaches.

And for those of us who have less than 60 years of history, it's hard to understand everything that was tried before Agile and the problems that they're trying to address. We typically just see how Agile's being implemented now in the industry that we're part of, Jim points out that they started in software by trying to apply traditional management approaches for software. And while they were able to deliver very large complex things this way, the harder they were to improve and become more predictable, the more frustrated they got.

The problem that became obvious as Kent Beck pointed out is that it's because software is a complex adaptive system. It was gonna need a different approach, an approach that could address all the complexities of software, but take advantage of its flexible nature. They came up with some guiding principles that I think everybody's seeing.

And the focus when they started rolling this out was, how do we work with teams that are developing software to make them more adaptive? It was all about helping the teams understand how to deal with these complex systems so that they understood how they're evolving, so they understood how to adapt. And when they proved a lot of success with these small teams, they started scaling into larger organizations.

The focus though was how do we scale these small teams into larger organizations? And it wasn't really much on what the role of leaders should be in taking a more adaptive approach. The best guidance for executives was to empower the teams, remove roadblocks than get outta the way.

Well, at HP we really didn't know any better, and we started leading the scale, large scale transformation. We took a fundamentally different approach, and I essentially, after looking back on it and spending a lot of time thinking about it, feel like we really did agile upside down. The leadership team was the one that was focused on trying to learn and adapt and respond to what was working, what was coming together.

And this leadership team over four to 800 developers that were doing a 10 million line of code rewrite of the laser jet firmware included myself as a director, had six or seven section managers that had three, we call them distinguished technologists, but they were the, the technical leaders in the organization and the program manager. And that was the team that was really trying to learn how to adapt and respond and take a more responsive approach. And it was a very large complex system that we were trying to optimize to deliver as much business value as possible.

And as a leadership team, we were constantly trying to understand how is this complex system evolving and how do we need to influence the priorities of the, of the organization to optimize the outcomes for the business? And we continued to go down this journey and every month we were, we were setting iterations, we were setting goals, and we're trying to learn how to, how to really learn, adapt, and respond to how the thing was evolving. And at the end of four years, what we realized looking back is we deliver a two to three X improvements in productivity.

And while we were doing this, we were letting the teams work in whatever method they choose. And when we look back, we realized that some teams had implemented agile practices and some didn't, and we didn't see dramatic differences in the results based on how they chose to work. At the same time as an organization, we deliver unbelievable breakthrough results that we couldn't have ever imagined happen.

This led us to the conclusion that in a large tightly coupled system, the first order of effect is the leadership team actively engaging with an adaptive approach. The second order effect is how the teams work. This isn't to say stop doing all the things at the team level that you're doing today.

It's more to say, if you wanna deliver the types of breakthrough results that you see on this slide, it's gonna take a deeper engagement and influence by the leadership team. And I've thought about this a long time and I'm trying to figure out why does it, why does it really take that more active engagement to really drive the type of results that you need? And I've come to the conclusion it's because the leaders are uniquely positioned to influence the changes that have the biggest impact.

They're closer to the business, so they better understand the strategic objectives of applications and the constraints of the business. And they're also better positioned to be able to look across the teams. And what we found is when we looked across the teams, that's where the biggest opportunities were for making the breakthrough improvements.

And anytime you do something like this, there's gonna be resistance to change, we're gonna have to influence change, and the leaders are better positioned for that. And I think what I'm telling you here is very different than anything you're hearing in the industry where, gee, as a leader, you should just empower the teams, get outta the way, remove roadblocks, and, and let 'em do their thing and, and try to measure them. And since this is so different, I think I'm gonna start with an example from HP of the types of things we did.

Not to say that you should do what we did or how you did it, but it's more to give you a feel for the types of things that the leaders are uniquely positioned to influence. And then once, once we've gone through that and give you a good example of those types of things, well, I'll review a more active role for leadership, including using some basic common sense principles that can be leveraged to address your unique, your unique situations. In 2007, I got an opportunity to take over leading HP's enterprise laser jet firmware team.

This team had been the bottleneck for the business for over two decades. We couldn't add a new printer to our plans or a new feature without checking with firmware. And usually the answer was no.

The firmware supported a lot of new and existing products with different versions of the code base on different branches. That created lots of problems. This was frustrating but tolerable until we started getting into copiers.

HP was investing in a new high-end copier and needed no excuses solution from firmware. This required us to integrate seamlessly into Microsoft's active directory systems for things like secure scan. The email, the leader before me had tried an initial release and then determined that this would require not us trying to integrate and, and integrate with W with Windows XPE and their backend systems, but more developing our code on their XPE platform.

Because at the time that was changing so much, we couldn't keep up with all the changes and if we just developed on top of their XP platform, we'd get that seamless integration and security. They'd also convinced the organization that this would require a complete rewrite of the code base. When I got the job, they weren't looking for somebody to create the plan.

They were looking for a leader that could make it happen. The objectives were clear, it was a complete rewrite on xp. It needed to have all the features of the existing code base or it wouldn't be accepted by the customers and it needed to be done in time for the release of a new copier.

This was non-negotiable. This is what we were chartered with this, this is what we needed to go make happen. But as I brought my staff and that leadership team together, we started looking at this and the traditional approach for this organization for a launch of a new architecture like this would've been going into a months long planning session to show it couldn't be done without more resources.

And then a few more months going back and forth with the organization to see what we could get in terms of new resources or not and what we could compromise in terms of our commitments. The new leadership team had seen this play out in the past and didn't want to do it again because we knew we wouldn't get additional resources. Instead, we focused in on making it happen with the resources we had.

And when we tried to figure out how do we execute and make this happen, we started by the, the program manager mentioned, well, why don't we just write down a list of the most important things we feel like we need to get done in this month and start working. And then at the end of each month and every month we would review what got done, what didn't get done, and develop plans for the next month. And it wasn't in isolation that the team said that came up with these directives and sent 'em down.

It was working with the organizations. It was spending time out there understanding what was working, reacting and reviewing and responding to that. And this was really our fundamental approach to, to really taking a more adaptive approach and spending time understanding how this complex system was evolving.

It was very different than anything we'd ever done before. We also realized that while the charter was for XPE for the copier, because we were, you know, in the leadership role and we understood the broader piece of the business, we also realized that XPE was expensive and if we were gonna have this be a solution for the broader business, it also needed to scale the Windows CE to be a viable solution for the broader product line. We also realized that all the branching that we've been doing in the past and supporting all those was really driving a lot of complexity.

It was driving our cost structure and we really wanted to move away from that and we wanted to, you know, develop all of our current and release products and all the new features on a common truck. The leadership team also understood that we needed to increase our investment test automation. There'd been some done up to this point, but not a lot.

We really felt like this was an opportunity where we could really ramp up and make a difference. These weren't things being asked for by upper management, and these are things I can't imagine being driven by the development teams, but we as leaders of the organizations realizes we needed to influence these strategic perspectives if we were gonna be successful. And that was one of the key roles we played.

We also spent a lot of time looking across teams to understand where the biggest opportunities are for inefficiencies. We realized when we were trying to bring together the architecture instead of coming up with a plan and then integrating it later and seeing how the plan came together, what we wanted to do is, is we wanted to have working code of the architecture. So we started with really thin slices for the architecture, putting it together end to end and keeping that code working on an end-to-end basis.

And this really did a lot to align the teams and put it together. And it was part of how we were seeing how this complex system was evolving. And as we got thin slices, we started creating more thin slices and we moved that forward.

We also realized that when the common, when the trunk became unstable, it impacted the productivity of everybody in the organization. So we started putting in quality gates. We also realized that when we had instability in our tests, we would end up wasting a lot of people's time and energy.

0 that was creating flaky tests and we realized we had to slow down and really make an investment in a different common test framework to get it there. And these are types of things that I don't think would've ever been driven at the team level that were required. A leadership team that was constantly trying to understand how its complex system was evolving so they could influence priorities across teams that improved the effectiveness of the organization and we're constantly out there learning and adjusting, trying to figure out what would work best.

And with any big change like this, there's gonna be resistance. Most of the developers in the group had been doing things the same way for years and were part of the team that had been EC for a couple of decades. What had changed was the leader and about half the leadership team, getting them to embrace new ways of working, required a lot of influence by this team.

The adaptive approach was completely new and just couldn't have happened from the bottom up. The way we used metrics completely changed. Instead of using it to measure and hold teams accountable, we used 'em to understand how the complex system was evolving so that we could understand what changes would help the organization become more effective.

And I like to say I used the metrics to go figure out where I need to have a conversation to learn more about what was going on. We also realized that several times, like the common test framework, we'd need to slow down for a period of time to get the foundations right so we could speed up later. And if the leadership team, if we were just holding people accountable to deliver to a schedule, I don't think we would've done that.

It took more of this adaptive approach of learning and responding. And probably the biggest organizational change management challenge was getting people to embrace a common truck. We've been doing things the same way for so long, they just couldn't wrap their minds around how this would look.

If we hadn't been so persistent on this as a leadership team, it never would've happened. And it was one of the biggest breakthroughs. There's a lot of other changes, but these are some of the ones that had the biggest impact on the organizations and they're types of changes.

Leaders are uniquely positioned to influence. By the time we completed the rewrite, we were doing things we never thought possible. We were bringing in 75 to a hundred thousand lines of codes of defect fixes and new features daily for all the products.

While keeping 10,000 hours of testing on rack, the servers passing the 90 plus percent. If you would've told any of the leaders in the beginning, this was possible. They would've told you you were crazy.

So how do you develop a plan for something you don't think is possible? You don't. Instead it takes a constant focus on influencing priorities and discovering what the team what is possible.

And that's a very different approach than what we typically do in organizations. And it's not what you're hearing from a lot of the software development community where really the role of executives needs to be in power of the teams, get outta the way and maybe remote some roadblocks. Hopefully this example has convinced you and helped you appreciate the power of having a much more engaged leadership team.

If you have a large organization developing lots of small independent applications or large applications that have been architected to enable teams to work independently, that empowering the teams and removing roadblocks is the right approach for all other big complex systems, you're gonna need an aligned adaptive leadership team to ensure the complex adaptive system is evolving to best meet the needs of the business. A team that's willing to learn and adjust as a system of as evolving. It starts with a vision.

You know, at HPR vision was to no longer be the bottleneck and to free up the capacity for innovation. We had a clear set of objectives and that drove everything we were doing. And I don't think if, if it weren't for the focus on that, I don't think we would've ever accomplished the results that we did.

It's not like we had an objective to go do DevOps or we had an objective to go do Agile or any of those things. We, we really didn't. We, we were focused on this vision, we were focused on our objectives and that drove what we were doing and we were spending our time understanding how the system was evolving and reacting.

The next thing when you pull the leadership team together is to have a common understanding of how that process works today, which is really hard with software development. Unlike manufacturing. When you go into the manufacturing facility, you can see it, you can look at it, you can understand it, and you know, everybody in the software leadership team's gonna have a unique perspective given their role.

And if we're gonna get this aligned leadership team, we need to take the time to make the process visible so we have a common understanding of the issues and we have a common understanding of what's slowing us down. Next. When we start influencing improvements, we need to understand the hardest thing is overcoming resistance to change.

One of the things I found helpful is moving past industry buzzword to common sense principles. When I use words like Agile, DevOps, T-D-D-B-D-D, et cetera, I found people have preconceived notions of what they mean and pre-prepared arguments for why I won't work here. Instead, I've moved to using simple common sense principles that are harder to refute and easier to adapt to your your unique challenges.

The goal here is to provide the leadership with some very common sense principles for talking about all the different types of improvements that might make sense for the organization. It starts with what to develop in the requirements in the planning process. And one of the biggest challenges to start with with software is such a complex system, it can be hard to predict how the customers will use it and what changes will deliver the business value.

Not every idea we have is gonna work. The key to removing waste and inefficiencies from this part of the process is getting feedback from as close to the customer as possible so we can adjust it and modify how we're doing thing to help deliver the desired outcome. Second, because of the complexity of software development, leaders frequently don't have a good understanding of the capacity of the organization.

Because of this, they end up creating plans that overwhelm the de development teams and disappoint the business. When the development organizations are over committed, it leads to waste burnout and build up a technical debt. They're just running from one thing to another and they don't ever have a chance to do it right.

And when the organizations don't deliver what the business expects, they start to lose confidence. The key to removing waste from this part of the process requires leaders to better understand the capacity of the organization to ensure they aren't over committed and can meet the business to deliverables while also ensuring there's always a backlog of work for developers. So they have something to work on if they finish the commitments early and that's the right priority that you wanna be working on.

The other challenge that a lot of organizations have with the requirements and planning process is they end up with so many requirements that they're working on that they tend to start taking on a life of their own. It's so much easier to create ideas than it is to do 'em that a lot of times you just collect this huge backlog and then you're managing it, you're prioritizing it, your whole meetings. And the key to really improving the efficiencies here is to limit the work that you put in on those requirements to just in time when it's needed to either support a business decision or enable to support development.

And if you're doing that, it gives you more flexibility to adjust and respond to what's out there in the marketplace. Once we understand what to develop, a lot of it comes into how, and then when I think about the how I think about the architecture and as the HP examples showed architecting for common trunk, the architecture approach can have a dramatic impact on the efficiency of the development process and the value of the product. The current or planned architecture can be be a constraint or enable enabler left to the architecture.

It will probably work but might not be optimized to deliver as much business value as possible. Gaining a common understanding requires not just an architectural map, but visibility into the implications of that architecture on the product and the development process. Does it require lots of different teams working together closely?

Other clean interfaces where it's easy to test separate components? Is it tightly? Is it tightly coupled to the hardware, which makes it difficult to leverage capacity in the cloud?

Is the current architecture inhibiting or enabling what the business needs? Once you have a good common understanding of the constraints of the current architecture, you need to decide if the impact on the business warrants the risk associated with the architectural changes. At hp, I didn't have a choice.

The job was to relight 10,000 lines of code from the ground up and it was the hardest thing they ever done. It put the business at risk because we couldn't release another product until it was complete and it set the Del delivery team up for a death march. Sometimes complete rewrites are required and maybe it was it's time.

If possible, I would recommend avoiding it. If you do feel like your current architecture is a constraint, look to a lot of the stuff Martin Fowler's done in terms of taking an evolu evolutionary approach to modifying the architecture over time. Without doing the complete rewrite, I think it'll be easier on your teams and less risk for the business.

The next part is how do we really improve the creative process of creating software? One of the basic principles is building in quality. Shifting to building in quality makes a big difference.

Manufacturing learned a long time ago that the only way to be successful is to focus on quality. They did this by controlling the process because the process was creating the same product repeatedly. Software is different in that it involves a person working with the business to create new and different solutions each time.

Instead of controlling the process, we need to work on giving that person the best bottle possible feedback on the intended and unintended consequences of the changes with the rest of the system. The quicker we can provide this feedback, the more help it is to the developers in terms of limiting wasted times associated with going down their own path. The magnitude of this issue can be made visible by macing.

The feedback delay and implementing improvements can be, movements can be occur by either moving the feedback closer to the developer or moving the code through the deployment pipeline quicker. There's also coming out a lot of opportunities with AI to really start making a difference. You know, at HP we realized that eventually our developers became the constraint and we were doing everything to make them more productive.

We were buying headsets, noise cancellation headsets, we were buying bigger screens to help them become more productive. And now they're just a bunch of things coming outta AI in terms of either code suggestions or ideas or maybe automatically generating, um, unit tests or trying to help you debug and triage. I would, if I were actively involved with a team right now, I'd also be looking at leveraging that to help you make them more productive.

And it's evolving quickly. And what I'm hearing from developers and organizations, it's just, it's starting to make a real difference in terms of the productivity of the developers. Software also has a lot of repetitive tasks.

Anything from creating an environment to building the software, to deploying, to testing. And just like we do in manufacturing, we can automate these things to make it more consistent. We can automate these things to make 'em more affordable so we can run them more frequently, which helps to reduce the batch size and make it easier to debug a triage, which takes a lot of effort in software.

And so these types of repetitive tasks are a lot of what you hear talked about when you hear people talking about DevOps. It's just how do we make these more repeatable? How do we work in smaller batch sizes and how do we go through that?

Software can also leverage some ideas that started in manufacturing. And this is, you know, how do we remove waste and become more efficient, um, over time? And Gold Rat has pointed out that you're not gonna get more through the organization unless you get more through the bottleneck of of the process.

And so he taught us the key to optimizing flow to the customer. We need to understand the source of the bottleneck. We need to make sure it's never starved for work.

We need to do everything we can optimize its flow and limit the working process for software. The bottleneck can be in requirements development or the release process. While it's possible for it to be in the requirements process, it doesn't happen very often because it's easier to come up with ideas than to implement it.

It's usually either in development or release. And the first step in improving flow to gain a common understanding of the bottleneck. If the bottleneck is in the release process, we should really be looking to automate the repetitive tasks.

So we can work in smaller batch sizes or at least more often if it's with the developers, which is kind of where we want it 'cause it's gotta be somewhere we can really work to sort of, how do we make them more productive over time once we get through that. So there, these are some very basic common sense principles that I think people can use to talk about instead of just copying, well this complex framework because it worked over here or it worked and did something else. The key to getting started is to engage the, engage the leadership to influence how the complex system is evolving to deliver as much business value as possible.

They need to be clear about what they need to accomplish and have a common understanding of the current process. They need to agree, agree on the improvements they feel will best address their unique challenges. Hopefully the common sense principles will make that easier.

Finally, to help overcome the resistance to change, I recommend working in small reversible steps, one iteration at a time. This enables the team to learn and adjust as they start making changes. With this approach that the team can stay aligned as they work when iteration at a time.

It's less important where they start. So they have the ability to adjust, to take advantage of the adaptable nature of software. And if we let them pick where they wanna start, they're much less likely to be resistant to change.

Thank you for your time. Hopefully I've convinced you that for large organizations where teams work together, there's a much more engaged and adaptive role for leaders. This top link is an 18 page paper that I wrote for Busy Executives.

That's the basis of this presentation. My goal was to rise to gold Rest challenge of if you don't understand the problem well enough, you can't explain it. Simply, my hope was to turn this into a book, but when my focus got on Clarity, got it down to 18 pages, it fit the time constraints of busy executives, but missed the marketing target as a book.

I chose to stick with meeting the needs of the reader and I would've written even less, but I ran out of time. There are other pages, papers in the resource tab on my website that ya also might find helpful as you're going off to different chances. And if there's anything else I can do to help, send me an email and I will try to point you in the right direction.

My email address is there and I tend to respond to things that I get. So thanks again for your time. Hopefully I've convinced you to take a different approach to deliver what your business really needs.

Hey, everyone got those post Super Bowl blues, we've got the Cure for what ELs you, you're watching Text Drunk Gang. Hi everyone, it's Alan Schmo. Happy Monday to you all.

It's Textron Gang post Super Bowl edition. Uh, we've got some, we've got some good stuff out from the webs that we're gonna talk about today. Let me introduce you to who's talking about it.

Um, our gang for today. We have, well we have some regulars, but, uh, joining us, I think she looks like she's home out there in New Mexico. She's the CEO of Deploy hub and involved in CDF and OSSF and a bunch of other good open source stuff.

It's our own. Tracy Reagan. Hey Tracy.

It's good to see you. Good to see you too, Alan. Great to be here.

Thank you. Moving from New Mexico down well, to the west of Texas, down to the east side of Texas, down Houston way, he is a FU analyst, CTO at Visible Impact Guy Courier. Hey guy.

Good to see you man. Hey, Don't, don't say Houston doing Austin night. Austin, Texas, central Texas.

Did I say Houston? Not East Texas. Yes, you did.

Well, that's right. Love Houston. Love my Houston.

But I happen to live in a great city of Boston, Texas, central Texas. Well, I where we Get warm, whether year round, whether we want it or not. Same here.

I apologized to all my friends in Austin there. I had a momentary laps. I think it was too much Super Bowl stuff.

Um, I was thinking you should apply, you should apologize to the city of Houston, but what do I know? Yeah, well it had something to do with the guacamole though, I'm sure. Um, anyway, guy, wherever you're from and are welcome, um, Gonna be here.

All right. And we'll move up from Houston to Austin to Colorado, our man in the Rocky Mountains. Mitch Ashley.

Hey Mitch. How are you man? Good.

Doing good. Happy Monday everybody. Happy platform engineering day.

I think we're gonna be talking about that. Yay. Great topic.

Cool. Mitch, you're still in Colorado, right? I am, yes, I am.

I have moved, moved and I'm not traveling. He moved. Alright, good for you.

Well, and then we'll round it out with the, uh, the, uh, Matt in Harrison, our chief content officer, Mike Azar. Hey Mike, how are you? I'm well.

You know, I can't figure out which President Harrison is actually named after, but I'm gonna look that up. Well, it could, I don't What makes you think it's named after a president? Good question.

I don't know, but I've been here long enough. I should figure it out. Yeah.

Well what are the, if it was a president, we've got William Henry Harrison, he's probably the oldest, right? Mm-hmm. Then there was another Harrison Post Civil War with the long beard, right?

That was William Harrison, wasn't it? William Henry Harrison? Yeah.

No, there was William Henry Harrison, I think is earlier. I think, I think one of them caught a cold and died. That's what, Right.

One of them died pretty quickly. Yeah. Got it.

Cold and died. Yeah. Well, that would be an interesting reason to name a town after someone.

There you go, man. All right, well look, report back to us on that, Mike. Yeah, I will.

I'd ask an ai get your agent. A Ai AI agents conference. All right.

Well guys, before we jump into our first block, you know, for those at home, we don't do these live If you haven't figured out, we usually record the day before, but being that this is a Monday show, we record it on Friday, well we, so we've got what they call a weekend in the middle. And this weekend, as I mentioned earlier, is the Super Bowl where the Kansas City Chiefs are playing the Philadelphia Eagles. So I, so I thought I would do a little experiment taking advantage of the time warp here.

I'm going to ask each of you to make your prediction for the Super Bowl score and winner today here on the show. People will see it Monday and real, and we'll see who was the closest and who wasn't. Right?

It's kinda like back to the future, you get to play Biff. Um, so Mike, I'm gonna ask you to lead off, what do you, what do you, what's your prediction for the Super Bowl? All right.

Realizing that I probably am not a fan of either one of these teams, but I'm going to, uh, go with the Eagles 27 21 over the cheaps Tight game, low score, relatively low scoring. I think the over is higher than that, but, okay. Mitch, how about you?

I thought you were gonna record this as, uh, two different endings to the movie, like, which, which team won, and then we can Well, no, I'm, I'm just doing that for mine, so I I, okay. You know, I, I come out right, but go ahead. Well, you know, in, in, in a typically tight score, 13 to 14 weird score, you know, um, it, it came down to the, to the, uh, Kansas City.

It was mahome at that last second to, to get that touchdown over the line. And, you know, the, uh, the Eagles weren't able to stop 'em given their great defense. It was, it was a pretty amazing game.

So it's 1413, you score pick. Yep. Mm-hmm.

Ooh, I love it. Tracy, how about you? Well, it doesn't involve a hockey stick, so I don't know anything about it, but I could tell you what chat cheap BT says, Okay, well that's as good as any, Yeah, exactly.

5. So there you go. Go.

That's my prediction. Go 13 s pretty close. So Kansas City, by a point and a half, I could guarantee you it won't be by a point and a half because they have Yeah, that a weird number have points.

You know, they don't have half points. I was, I was taking candy from a baby, You know, but, but, but, but now you put this whole idea of chat, GPT as a bookie in my head. And that's a whole other thing.

Oh, it has the spread as well. So if you wanna know that, let me look back again. It says, uh, a money line of minus one 20.

Okay. Very cool. I'm not, uh, I don't, I'm not enough of a gambler to know what that means.

I'm sorry. I Don't either. I don't know that one.

Okay. How about you? Uh, I think the Chiefs 5, 9 35 to 26 with one defensive score by the chiefs.

So take away and defensive score by the Chiefs. That, that sounds interesting. So I'm gonna go with my heart rather than my head, which is probably not a good move when you're betting.

But I'm gonna pick the Philadelphia Eagles in a shootout, 42 to 36 a shootout. And there'll be some defensive touchdowns too here on both sides. You know, there's gonna be turnovers.

I think there's gonna be a high powered game, though. Both teams have a good defense. Anyway, you're watching this on Monday, who, look, maybe we hit it, maybe we don't.

But Mike, let's move on to our first story for today. Okay. Why don't you, uh, take the reins.

Yeah. com. We invite you to go over there and check that out.

'cause there's a lot of awesome, great content starting to show up over there. And it's a hot topics these days. It's a lot of debate about exactly what it is.

And, um, there's, now the CNCF has a set of certifications that you can get to become a platform engineer. And everybody's kind of trying to figure out, well, what does it mean to be a platform engineer versus, say, a DevOps engineer? Mitch, I know you're following this space.

You did some survey work on this last year, but what is your sense of, what is the difference here in, uh, 'cause it is platform engineering something a DevOps engineer does, or is it an actual different job with a different title and a different role? Well, I think you, first of all, you have to take the certification to find out. That'll answer your question.

Uh, at least according to the CN Yeah, no, it, it's interesting. You know, platform engineering really kind of accelerated its emergence, uh, during the, the post covid. Let's focus on developer productivity.

We need to get more out, more for less, you know, with our developer community. Um, 'cause finances are getting tight and things like that. And, and, you know, some folks, it's, uh, we've been doing this all along.

This has been this admin work, or we called it ops something or whatever. That's true of a lot of things, right? We do many of those things and then we kind of package 'em together.

I think the difference is we're playing d different kinds of disciplines to some of those tasks. And what has emerged to be is, first of all, making sure, in particular developers, but also testers and others have readily real, readily, readily access to tools that they use and somewhat standardization on those. And also support of those tool environments.

It, it's more than just, you know, hanging up a bunch of spurs on the, on the wall and say, you know, pick your poison. Go, go ride one of those Broncos. It's no, it's, it's like, here, this is what, where you develop code and here's the id.

You can choose your id, but here's the plugins to use. Here's the, uh, you know, repository, et cetera. But it's more than that.

It's also trying to create standardized configurations, maybe more secure configurations, supporting of those things. It could be for platforms, for development, for testing, for different production environments. A lot of organizations run, especially if you're a SaaS company, may run different versions of the same app, right?

And for different customers at different times. So it, it's the other area where it's really grown into is also also blending and kinda merging with DevOps. A lot of platform engineering teams support all the DevOps tools too.

Why separate those? It doesn't always mean it has to be that way, but it's certainly kind of easy migration to move that way. Um, I, I wanted to highlight too, Alan is started a new podcast, the DevOps platform engineering podcast with Luca.

And I'm sure you'll talk about that, where they talked about, you know, the old adage of his DevOps dead and platform engineering is taking over. There may be a few stalwarts that are holding onto that adage, but I think most of us know that's not true. It's really accelerating how we do DevOps and scaling it.

I've got some, so Mitch, thanks to the plug the show is called the Platform Engineering Show, right? Plain and simple. There's an interesting move here on ccf F'S part though, right?

They, in addition to rolling out their certification, they're also, I think it's only the first or second time at Q Con London coming up, where on Monday zero day, they're actually having a platform engineering conference, you know, as one of the conferences that they do, usually on Monday you get, like all of the projects get to do their show. Some of the daughter foundations do a, a gig and then some subjects. In the past it's been, uh, security Cloud, native Security, and OSSF started this year.

They're doing a platform engineering one. And from what I, uh, gathered, uh, Chris Ek, the CTO of, uh, cloud, CNCF said that it's, it's, it's like they're one of their most popular electives for that Monday zero day, uh, of, you know, lineup. Actually it might be Tuesday is zero day, it's Tu no, it, it's Monday, then Tuesday.

No, it's Tuesday. I apologize. It is Tuesday.

Then Wednesday, Thursday, Friday is the actual expo. Tuesday, zero day, not Monday. Monday zero day and RSA.

But the point I was trying to make, what was the point I was trying to make, the point I was trying to make is my friend Luca, that Mitchell references Luca Ante. org. They're the people who put on Platform Con for the last couple years.

And it's probably the single biggest platform engineering conference. It's virtual. Oh, this year it'll be hybrid, uh, in the world.

They get 25, 30,000 people registered for that thing. Um, they've got about two to hundred to 300,000 people on their community chat. And, you know, all of that.

They have all kinds of working groups and, and reference architectures and everything else. One of the things they have is a training certification course and platform engineering. So here we go again.

org certification or course the right one for you. Do you want to get both of them? Interesting?

Usually these break off into the commercial versus non-commercial, the vendor versus the org kind of thing. But here you both, you've got two not-for-profits, two, you know, communities with dueling orgs for what is, according to Mike and Mitch, maybe not as well as a defined a, uh, not as defined as some of the others. So, you know, I don't know.

I mean, CNCF kind of has a bit of a minus touch right from there. Yeah. Don't these things tend to run on vibes though?

Like, you guys have been paying attention this far longer than I have. I I feel like, you know, could be, you know, a movement, whether it's an anti CNCF movement or just a pro platform engineering movement because of whatever, like the purpose. There's a, there's a good, helpful purpose in this education certification.

It's a way of someone saying, I I I I've studied, I know, right? But the reason they're doing it is to get a job, to get a promotion, what have you. And the reason they're accepted is so that, uh, people hiring you can have confidence and that can come from multiple organizations, is just by vibes.

I mean, there seems to be some sentiment that comes out of the soup of culture and community and all that stuff. And one becomes the one and another one disappears or becomes the other one. Uh, it's, it's as random as that.

No. That neither of these organizations gonna do a poor job of training and certify. org, I mean, certainly today has a much larger community of platform engineers anyway than perhaps CNCF does.

That's one of the things I was thinking, Alan, too. org community is a very fervent, passionate, engaged community. And kind of kinda like early DevOps days, but maybe even more so, just a really strong vibe building.

Yeah, no, they've done a good job of, of organizing Luca and Yeah. And the team there, it may propel it to be the leading certification. Maybe it'll be unique and different that way.

Maybe enterprises will look more to CNCF. Who knows what'll happen. You know, I, I think the platform engineering certification though is more, you know, more of the unconference unconventional, you know, you may be able to just take the test and not get the certification, but I took the test kind of thing.

'cause you know, there's a, some people revolt with the idea of, of having a certification, you know, too structured down with demand. They, A lot of them will say that the test is just people who are good at taking the test, pass the test. No, it's a DEI thing.

It's a DEI thing. I, that's where my head goes immediately when I think certifications. I was like, you know, I want someone who's gotten their hands dirty and done this.

And even if it's in their own environment, they stood up a raspberry pie and they've been installing things and figuring out how to configure it and understanding how to start automating some of the configurations. So, um, it doesn't, you know, it gets certified. It's a really good thing to do, especially if this is an area that you've not been in before.

But we've had operations people and production control people for forever, right? They've been there forever. So why is platform engineering a discussion now?

Well, I'm glad it is because we have far more complex production environments or any environment test development environments than we ever did before. If you think about a, a, a monolithic application being deployed to a Windows server, for example, pretty, actually, it's pretty straightforward and simple. And you can have a, uh, a either an SRE managing that, uh, you can have a production control person or a, a network engineer even managing that.

But when you start thinking about the complexity that we're going to see that we already see in just a Kubernetes environment, and then add AI to it with hundreds of AI agents that have to be configured with traffic going to all of them, that has to be looked at and managed on a regular basis. We are in a new world when it, when it comes to production control and, and what we're calling platform engineering. And it's good that we're, if, if it's true what Mitch has pointed out, that we may have DevOps and platform engineering in the same department, or at least working close together, I would love to see that because these platforms are built on a lot of scripts, and that's where we shoot ourselves in the foot or the face sometimes can be even more dangerous, right?

Because scripts are obfuscated, they're hard to go look through. And if we start doing more things in a templated way when it comes to platform engineering, we think of things like Terraform and, um, you know, open tofu. These products that are, are trying to help us through the process of templating and understanding and being able to repeat the creation of these environments, the better we'll get and the more prepared we will be for these broad AI environments, and it'll give us a better opportunity if we choose to, to move off of a, uh, AWS environment and into our own.

So it's, it's, it's the, the time is right, the conversation is correct and go get certified. Uh, because if you haven't done this before, we'll have more jobs in it. And, you know, the Ortel team, this has been such a discussion for them.

Um, one of our, uh, committers did eight, a series of eight blogs just to teach how to use all of these different tools. And there there's a lot, there's a lot to learn in it. So get your hands.

I'm so glad you used the, uh, you mentioned the SRE because I, I, I felt like, um, SRE had its moment and SRE were mountains striding, you know, uh, uh, infrastructure gods and goddesses who, uh, went around saying, you know, like, we, we are going to make your environment secured, solid and reliable and all that stuff. So you keep doing all your fun DevOps stuff. And I, I, I was a little confused by it mostly 'cause of the name.

And my impression was that the idea of platform engineering as a, as a discipline arose healthfully out of site site reliability engineering, because it reached up into what really matters, which is the application, its functionality, and what people are trying to do with it, and with data. And, uh, uh, uh, uh, Ronnie Engar, uh, from Cloud Foundry, uh, uh, posted a really nice perspective about how the phrase platform engineering seems like marketing, but engineering a platform definitely is not. And I feel like it gi that name and phrase marketing or not, gives us a really good focus on what, what is needed in this, as you say, increasingly complex, interconnected, um, multi requirement to host a requirement world for any application, which is somebody who is going to be not, not ensuring the reliability and functioning of an infrastructure, but someone who is engineering a platform to serve the business interest.

So I disagree, it's guy, they do have to do, they, that platform has to be reliable. Sure, sure. But that's, that becomes that, you know, it, it almost subsumes the SRE function within the platform Engineering SREs.

So look, these are all interrelated under this bigger umbrella that I call DevOps. But I've had a chance as part of doing this platform engineering show and talking to the platform engineering or people and some of the community there. It's not as nebulous as you think it is, and it's not necessarily just ops by another name and, and stuff like that.

And it's not meant to replace DevOps in spite of what they said from a marketing perspective. Here's the deal as far as they see DevOps is great, right? The, the whole kumbaya, the whole cultural, the whole idea of breaking down silos, working together, when you get to large scale, it's hard to organize that chaos.

And increasingly with DevOps, there was this shift, left shift, left shifted, left, shifted further left, not left enough, shifted it more left, where all of a sudden the mantra became where the developers building his own platform that he develops on. And that's, that's when, that's when the, the stuff hit the fan. The developers shouldn't be tasked with building the platform they develop on.

And wouldn't it be better if someone who is supposed to, who's certified, who is trained, who is experienced building a platform with the guardrails that allows the developer that then just develop, he doesn't have to build this platform or her platform. They develop their code, their apps, and they go faster. So, well, I'm just not sure where we're disagreeing, Alex, because I Created all that.

I, I would argue to a certain degree you would get a lot of folks who would say that's exactly how it used to be back in the day. And then the developer guys rebelled and said, we're gonna go out and build our own tools and platforms because you guys are too slow. And now it feels like we're coming full circle.

So people are standing there scratching It. Isn't that the way of the world? It's always been that, that Started around 1970 with the PD P 11.

Like, yeah, We've always done That circle of life. It's the circle of life circle Of, but there's a part of it, there's a part of this discussion about who's accountable. So for most of you out there listening, I'm sure you will know and, and experience this, is that if there is a production problem, who gets called to look at it and fix it, the application team, even though they don't have access to production, they have somebody else who might be sitting there with them trying to sort out the problem.

So we created a site reliability engineer who could have more control, but they were assigned to a team. But as Alan points out, they were also trying getting, having them do the hard work of actually building out the, the, the platform. So these, there is a, there is something that we used to talk about called separation of duties, right?

So we've constantly tried to, to achieve that separation of duties by having an SRE who might have production access. And he's the person sitting on that team working with them. Yep.

That person should still be there. Yep. But there should be another team that is managing the platform itself.

These are very different discussions. I I agree. The platform is different than the application that they're managing.

So we need the platform engineers to start standardizing and, and, and stabilizing these, these environments in order for us to move forward. We can't move forward without having that. There's another thing happening here too, Alan, is I just wanna note that I obviously talked to a lot of vendor technology companies in my role and as does Guy and more and more sort of platform engineering advocate is the new dev rail.

It is the, it is the focus of companies because things come together at platform engineering where it's developer tools, it's, uh, Kubernetes running and production are running the underneath the tool chain security is starting to kind of connect there as well. I'm not saying it's the center for all activity, but a connection point now. And we lacked that before when developers are creating platforms and doing all the supposedly operations themselves, but not.

And so it's, it's, the market has responded to, I think, what's happening in, in the, uh, you know, development community. Just as an example, the latest one I was at, uh, Dynatrace, uh, last week, Dynatrace performing, you remember. And Andreas Grabner, our friend at the CNCF, he's a Dynatrace, he's now, you know, uh, uh, advocate for, uh, platform engineering.

He gave a whole talk about it. And that's clear as I talked to different people at the conference state's, very much was state, wasn't it? Mitch wasn't.

And Andrea's CEO state, um, he was warland and then he, I can't remember where he was before. Well, I didn't know New out of the Netherlands. Yeah.

With some of our, uh, uh, the Cloud D marketing, some of the folks from there moved over there and, uh, oh, state by the way, uh, um, who else was it? A, um, someone else was there that I saw? Anyway, there was some old friends that we have, um, good folks that we have on different, different, uh, uh, on different, uh, things.

Anyway, the the point was, you know, it was a whole main stage conversation. We're talking about platform engineering and they're all, it is main stage guys, we gotta move on to our next topic. I'm gonna take the prerogative here to have the last word.

You know what, all these people you're talking about work in the software factory, right? Kind of father knows best Dad went off to work in the factory, and they all work in the factory and there's a job there for all of 'em. And it takes, it takes the village to build our software and run it today.

So we have SREs and platform engineers and DevOps teams and developers and testers and all the, all of the things we need to make software what it is until AI comes along. And I'm only kidding, I don't know what AI's gonna do. We're gonna take a break.

We'll be back in a minute. Discover Techron group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide.

Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients.

Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group. Hey folks, we're back and we're gonna continue this conversation a little bit with a little more focus on DevOps specifically.

'cause there's a lot of debate out there now about, well, does DevOps scale? Is it broken? Other folks say, Hey, you know, look at all the great software we're putting out there because of DevOps.

So maybe two things can be true at the same time, even though they're at polar opposites. com, done by Port Inc. They are a provider of a internal developer platform.

So they definitely have a stake in this conversation, and they only talk to, you know, very high-end teams. But they found out that, well, developers are wasting a lot of time and more troubling still, it suggested that half of them don't trust the data that's actually in the DevOps platforms and tools. And that kind of stuck out with me as like, well, if I'm not trusting those tools, then what am I doing?

Just calling up people and asking them where things are doesn't sound very efficient to me. But Tracy, I know you've talked about this in the past where DevOps is broken, but the question I think is how broken, where is it broken and what, what can we do to make it better? Well, I wouldn't say DevOps is broken, um, but I would say that DevOps needs a bit of a tuneup.

Um, but going back to that survey, I read, read through that survey, and sometimes things don't feel right to me. And it may be, but one thing in there said that an average number of tools was seven. And I'm thinking seven.

Just seven tools. Is that all? I think it's missing two digits.

I at least one digit. Right? At least one digit.

I mean, I probably can come up with seven tools right now just thinking about what you know, are in common. DevOps pipelines takes seven About if tools to manage the 70 or 700. Yes.

Right, right. So that's maybe It's, maybe it's seven approved tools and the rest are whatever I can find. Well, there are, we, there are so many.

And that's the whole point of a DevOps pipeline so that you can manage the tooling. Now, I know there's been to, there's been, um, similar tools that Port does, like task talk. And I do know that there is, uh, you know, having a layer that helps make this stuff easier is important, but I still don't feel like having seven tools is a problem.

So I had to question, it made me question the, the, the, the data in the survey. Just go want the whole thing. Yeah, Iop, Jason, DevOps does need to need, we're at a point that DevOps needs two things.

We need to add security tooling to it, and we need to start adding what we need to do for, uh, testing, you know, LLMs and ML ops. So while I, uh, you know, question the survey, I, I wanna point out that we do have a lot more tooling that we need to add to the DevOps pipeline. And seven is probably a, a very small number.

And if you only have seven tools, you may not even need a dev pipeline. Yeah, I I, but I felt Tracy, like, it was like, it was like, um, bad data supporting a good point or something like that. I don't wanna call it bad data.

No, it was a self, I dunno how they conducted this prophecy. See, yeah, fair enough. But the point is like, you know, I, I think the contention that developers, um, to, and, and specifically this is seven tools to build whatever build means.

It doesn't mean to deploy or to, or any of that sort of thing, like necessarily. Um, but, uh, the, the general idea that, uh, there are a lot of multiplying tools or let's say use the word platforms again, the developers are navigating on average, um, instead of having something that's a little more integrated in seamless, if you like, um, that is kind of an issue. There's a lot of BYO there's a lot of stuff that's going on and I, I, I, the survey attempted to val validate it in a poor way, but I think it's a real issue.

I do too. A hundred percent Chase, I don't disagree with you and I and Guy, I don't disagree with you either, but, but lemme that's, that's a, I agree with that. Now get straight, Hang on.

I gotta write in my diary real quick. Alright, Lemme, lemme just get this straight. A software vendor who makes an internal developer portal puts out a survey that says, developers say, the problem is they've got too many tools.

They could use a portal to help manage it because they don't believe the data and metrics in the tools and platforms they're using. They wish they had a portal to use. And what do I sell?

A portal? Come on, you wanna talk about self-serving much? We, we, I think we already established that point.

The point Is, well, I just wanna make sure we, we hit it with a big fat sledgehammer. The, The point is, the point is, in fact, we wouldn't be talking about platform engineering if everything was hunky dory in the land of DevOps. So things Are not Well, that's okay.

It doesn't have to be hunky dory. Life isn't that way. It's not all unicorns crapping rainbows.

That's not what the way the world works. There's going to be issues, there's gonna be problems. We keep working at it.

We, we constantly improve continuous improvement, right? Iterate, reiterate. Now that being said, here's where I do think you have problems in the DevOps tool chain.

As you get to the enterprise level and you're at enterprise level DevOps, it is a very rare bird deed where you have a standardized tool set, whether it's seven or 70. You don't have standardization of tool sets in your DevOps tool chain because this team chooses to use Jenkins. This team might be doing GitLab, that team's doing harness uh, testing.

I'm doing t tricentis, I do sauce, I do pure open. I, I'm, I'm running coop here, I'm running VMware there. It's the enterprise.

We don't have standardization of our tool sets. Well, Alan, did you just keep in mind the punchline here, which is supposedly 15 hours of loss productivity per developer per week. But if they use a portal that gets cut by 90%, Well, yeah, sure, but that, that's the, that's the who cares part of it.

Because, you know, part one part is the, it's a culture of, you know what, innovation, freedom, trying things out, break fast, all others, or you do wanna enable that. So is it really 15 hours of wasted, wasted based on what, you know, like what's the point? I I don't think it's 15 hours wasted, but here's the point in my mind, there's this eternal combat between let's get efficient, let's slim down.

I want one throat to choke. I want less tools. We got too much, too many different software here, too many different security tools, too many different DevOps tools.

We've gotta, it's, it's, it's, it's wasteful. It's inefficient. We've gotta standardize, we've gotta standardize until I buy the next company.

And they have their own way and they dig their heels in that they're not going to, you know, this is what they use to go change. Something's gonna be a major to do it. It's the way DevOps evolved, right?

DevOps very rarely came from the top down enterprise-wise. My theory always was we, DevOps came in bubbles. And you know, like when you're a kid playing in the bath with bubbles, as bubbles come together, they make bigger bubbles, and then they get bigger bubbles and then they pop.

And that's how DevOps evolved and that's how DevOps rolls out in enterprises. They're, they're these bubbles of teams that use their own recipe And they, and I think sometimes the, the mistake that we make is thinking about DevOps as tooling. When if we really built a DevOps, uh, framework, it wouldn't be based on the name of the tool.

It would be based on the, what we're trying to achieve at each state in the process. So a compliance scorecard, for example, so that every team can build their own DevOps pipeline because one's doing Java, one's doing Python, somebody else is doing rust. Because these environments are very, very different.

The compilers are different, the tools are different, but you can still define your compliance levels that you need to achieve. And we will end up with lots of tools. It's just going to happen.

And there's probably another 10 tools that we're missing in the pipeline just to add for security from repo scanning and signing to gathering, uh, data to doing vulnerability management on the out on post deploy. There's a lot of work we still have to do, but every single environment's gonna be a little bit different, even in SBO different, lemme show you Just a, just look the data with you, just to give some perspective, because I'm wrapping up a new survey that'll be out probably in about three weeks. But we, we asked organizations, where are you on the maturity curve, both for DevOps and for platform engineering?

And interesting, they're almost exactly the same in terms of the phases. The, the way I've always characterized it as other than, you know, once you're past the getting started phase, you go into kind of operationalizing how you using it, different teams are doing different things and learnings, and then you enter this standardization phase where you start to boil it together, right? Especially in the larger organizations, eventually get to what you might consider your own level of mastery.

And both for platform engineering and for DevOps. They're both right about 44, 40 5% in that standardizing phase. This is at the same point in time.

At the same time. They both say they're about 25 to 26% in the mastering phase. So they're really in sync.

And I think that's not by accident. Um, you know, these are talking to the same organizations. So I think they're moving together and, and fortunately I think that all also says that DevOps isn't staying stagnant, whether it's platform engineering kind of bringing it up, modernizing it, or they're both just heading in parallel and their kind of paths and working together, whatever the per whatever the reason, I think it's a good outcome.

But that's what the data says. All right, I'm launching a new, I'm launching a new platform engineering, um, Platform. I'm gonna call it Mr.

Bubbles. Okay, You like that? I just wanna know, someone already had that name.

I just wanna know, uh, I, I don't want, I don't wanna know the source of those bubbles, Alan, but that's whole nother thing. Well, you never, you never played with Mr. Bubbles when you were a kid.

You didn't have Mr. Bubbles. Yeah.

And, but I know that's not the only place that those bubbles come from. It was like a little purple box with all the bubbles. He had eyes like googly eyes and your mom would pour the powder in.

It would make all those bubbles. As long as they're purple. I'm so sorry for you.

If you didn't have a, a night with Mr, there's some things we just didn't have out there in the cornfields where I grew up, you know? Oh heavens, the cornfields. I didn't grow up in the cornfield.

Meanwhile, I'm thinking Scrubbing Bubbles. Mr. Tell the truth guy.

You didn't have Mr. Bubbles. Oh, I had Mr.

Bubbles. Yeah. Come on, Mike.

You had Mrs. Bubbles course. We had, I also had Scrubbing Bubbles afterwards Also.

I used the name, so of course we had it. Yeah. Oh, that's all we got.

What can I tell you? All right, let's, let's take a, explain a lot of thing about Nebraska. There you go.

Yes. That does. Poor guy never had Mr.

Bubble. Imagine that. No wonder why you would making jokes about other bubbles.

Necessity's the mother of invention out there. Just, just saying. Just saying.

Okay, we're gonna take a break. This is degrading quick. We better.

Let's get it together. We'll come back for, uh, part three of our episode today. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com. Home of security bloggers network. All right folks, and we're back with more IT issues.

And this time we're talking about the eternal quest for the Unified IT platform. And you gotta wonder if this is a unicorn or not, but JumpCloud has a annual survey out talking about how this is what folks really want. I'm just not entirely clear it's gonna ever be possible.

Guy, you've been following this a long time. Now we have more tools and platforms across all. It, it's not just DevOps or platform engineering.

Is that just the way it's gonna be? Or can it one day get rationalized into some Uber platform? Uh, without mentioning ai, no.

Maybe with mentioning ai, no. I think, uh, how many times have we heard the pitch for the so-called single pane of glass thousand times, 2000 times? I think that, um, back in the day, uh, I led most of my Forrester research.

There was a really helpful ship to thinking instead of a single pane of glass, the preferred workspace. And thanks to the cloud and the rise of the API economy and all that other sort of stuff, we do have real possibilities there. So let's back up a step on, I, I read the story and, uh, the, the specifically it was for device, uh, and role, um, management, um, some and identity management that there was a desire for a single tool, unified tool.

But it does bring to mind the perpetual 'cause. I, there are other service methods, fact, I just conducted one myself. Um, where there's a strong desire for unified, uh, management.

Let's say if forget a tool per second or painted glass or portal unified management of let's say ser uh, service health or, uh, infrastructure health or whatever it is, here's what's working against it. Two things really. The first one is, uh, IT itself is not unified, particularly they're security experts and networking experts close to each other, but have different agendas and need their preferred tools to help or their preferred single platforms.

Um, there's, you know, identity management, device management, which are related to security. They're all related to each other. Um, but even in a small shop, uh, there will be, for example, vendors and consultants who are helping to manage certain elements of it that whoever you haven't have in your IT shop can't do or shouldn't do, or you don't want, you don't wanna hire to do.

So you're having multiple roles here. And even a lot of these, you know, really comprehensive, uh, it service management platforms like ServiceNow or DMC and so on and so forth, um, they, they, they struggle to unify operations for the simple reason that as, as this is the second part, which is that as, uh, the nature of infrastructure and application delivery and so forth evolves, um, there are new specialty tools that come up because the big unifying tools can't do everything everywhere. So the API economy helps put all these together, but I think the idea of, um, unifying is the unicorn and maybe a, a helpful nor north star for everybody to think about, um, how to, uh, manage their entire estate and their whole landscape.

Um, you know, how to put things together so that people, individuals and talents that they have on staff as well as developers, as well as business users to a certain degree, can all have their way of doing their jobs that still somehow interacts together with each other. But that is complexity and it will be a perpetual struggle in every operations team to, um, make things easier for the users, easier for them. AI does show real promise in this area because it can, uh, do, uh, analytics including predictive analytics on very large data sets.

So a large state doesn't really phase it particularly, and it helps concentrate the human operators on the areas of the most interest and concern, whether it's, you know, uh, device management and security or, or, or system health or any of those other sort of things. But in the end, unless we go down the rapid, uh, Saachi Nadella told us that we're just gonna have our AI buddies and, uh, we're not even gonna be using portals anymore, which is a, not even a unicorn, it's a mirage. Uh, no, we're, we're, we're, we're not gonna get there.

Well, I, I just, if you aren't aware that February 28th this month is, uh, when we have the Great Planet Parade, and that's when we'll have a unified platform. It's when we have Neptune and, and, uh, Pluto I guess, and all the other planets line up. Pluto's not a planet Mitch.

It is, it's still a planet. Dammit. And, and Nebraska, it is, I guess where they don't have MR Bubbles.

But either that, either that or it won't matter anyway, because in, in 2032 and afterwards can hit Earth and even if we had the platform, we won't be here to enjoy it. But no, actually I did find there is one platform through them all. It's called Precious.

Oh, okay. The one ring is, uh, yes, is not, is not here. It's the one platform, One of the ring.

This is the pendulum conversation, right? We need one platform, we need more tools. Oh, I'm hypnotized.

I don't think it's a pendulum. Uh, Mitch, I think that this desire, it has been perpetual. You ask people, you've talked to customers probably more than I do.

Um, I talked to a fair number of IT ops folks and they all want it. But then when you dig in a little bit and find out what the one platform is they want, it's actually the one platform that covers this part of the, the infrastructure because it from and all those other sort of Stuff. Is it from Microsoft or is it from Azure?

Okay, let's let's decide that first, right? I Dunno, I dunno if it's one platform they're looking for, I think what they really want is a single place to go to find out what tools they can use, right? Because there's more than, you know, a handful as this survey indicates.

And we did, we've done that. We've had c MDBs in the past where you could say, Hey, I'm gonna go stand up my environment. I'm gonna download this version of Oracle.

Or tools like a bit that, you know, made an effort to pull together. This is where you can go find these on these different, um, repos. And I, I feel like that's really what they were talking about more than having a single platform one ring to rule them all.

And I understand that. I understand that desire, but we've done it. And I don't, I don't, I don't think anybody's gonna spend money on it internally.

I don't, Let me see if I could bring some order to the chaos here. I think you were gonna say something else, but go ahead. No, no.

So Cut through the, Yeah, let me cut through to the, to the, to the heart of this. First of all, shout out to JumpCloud for doing this, right? For those who don't know, JumpCloud is founded and CE by my good friend, Rajat, Ava.

Raj Mitchell and I co-founded still Secure 25 plus years ago. I've been involved in JumpCloud on a personal level since the day they started it. And know a lot about who they are, what they are, and what they do.

And I'll shout out to Greg Keller too, their chief strategy officer, another friend there who's does great work. So hi to Greg and Raja, if they're watching JumpCloud wants to have a directory that rules them all right? They, they think ad active directory, it doesn't work in the cloud era.

It doesn't work with Max so well, it doesn't work with cloud resources, it doesn't work with IOT with machine. You know, AD has has had its day and they want a cloud directory. It's a directory to rule them all.

And why having that directory is, is not just identity based so that when you log on, I know it's Mike or Guy or, or Chay or Mitch, but it also makes it very easy then to give you access to my tools to, to your tools that are pre-approved on the corporate land, right? 4 tools we spoke about on the last segment. And you, you know, I don't want to use the word single sign on, but single sign on, right?

And so does that sound appealing that no matter what device you're on, where you are, I could sign on and automatically get access to my tool sets and files and everything I want. Yeah. Surprise, 85% of people want that.

Shocking. Mm-hmm. Shocking.

Well, I think the issue comes more towards, you know, and I remember having this conversation last year with a CIO in, in New York who was particularly colorful about it. And he was saying, you know, the problem with every time I get a new frigging tool is I gotta go hire somebody else to go manage that tool. And then everything in the costs all go up.

So he's like, you come to me with a new tool. He says, forget about it. I don't wanna hear about no more new tools.

Was he a CIO? Is he a construction guy? He's he's a, he's a, He's a, he's a, he's a Hardcore drop them over here.

He is a hardcore New Yorker who is not having it anymore. And he was saying, you know, I, I have these platforms and if I need something, I'm gonna beat them up to give it to me as a feature. But I am not adding any more new tools.

He was About these guys in your tools, you guys Tools, I think we're talking about two different things though. 'cause one that you're talking about, Alan, and I think you've touched upon as well, Tracy, is is features, capabilities, uh, uh, them being cross platform integrated, that sort of thing. My lens on this is RA really the, the operations standpoint.

I think the desire, I know the desire for single tools or unified tools comes from a craving for visibility and abil and an ability to be proactive. Because what none of these folks want CIO VP of, uh, ops or infrastructure, um, application managers, uh, enterprise architects, they, they, they, they dread the midnight call. They don't want the midnight call anymore.

And what they fear is that they have these six tools and these six people on the six tools, but then tool number seven happen to have a yo-yo working that day and didn't see something and trying to, the comprehensive idea is that they can organize all of it in one place and see everything going on in one place, and they get the little red lights in advance and they help fix it, and they're being proactive and they get few or no of those, what happens? Something's down, everybody's gotta pile in and figure it out. I think that's what, what it's really from the operations standpoint, that this desire for uni, it's to give for unification comes from, is to get a full and complete view.

Not of what's happening now or what happened just a minute ago, but you know how to ensure service health for the whole stack going forward. And every time you add a tool, you don't, not just adding a person, you're adding a, a dis uh, an interaction point, um, a potential weak link in a chain, all that sort of stuff. That's, and, and they hate that.

They hate that part of the job. And the part at the time when this is the most critical to have this kind of a unified platform is when you're onboarding new employees, you want them to be able to come into work and in a few days have everything that they need. And, you know, I've seen organizations take two or three weeks for, uh, a single developer to get all the tools that they need.

'cause it takes so long to figure out what it is that they should have. So there's a point in time that this becomes super critical and then you forget about it. Yeah.

Now I think we're back. So, and I, that is the jump cloud kind of vision right there. Tracy guy listening to you, I'm reminded of, back when I was in inter reliant in the late nineties, we were in a SP and we had this whole lineup of apps.

We were hosting Oracle peoples, so PeopleSoft, Onyx, you know, late nineties apps, pre-cloud. And, and we were trying, and we actually called it a miracle layer that would sit below all these apps and let us manage them, provision them, build them, you know, do everything from a unified platform and that we would be able to plug more applications into. As you know, they pop up.

It's a bit of a holy grail. I I don't know if we ever quite find that. I think we're really talking about two things.

One is, you know, there is no one one tool that's gonna solve all the, yeah, it just, not, even if there was, it wouldn't stay that way, right? Something else would come along would be, that would disrupt it. So we really have two things.

We have, we have portals that get to help you with that onboarding. Here's the set of tools, here's the capability, here's all the stuff that you need to kind of get started, right? You don't have to go looking for tools.

The other, the other trend is towards what you're talking about, Alan, which is platforms, which isn't one thing to rule them all. What they are is a set of pre-integrated capabilities, usually from one vendor that also shares data across those tools. So you're not, and also between the integration in the data, you're spending less time in the tools management, integration support business, but they all have to have very rich integration capabilities and not just lip service to integration to third party tools.

'cause people use other stuff. Maybe there's testing capabilities in the platform, but I'm a Trace Sentis customer. We've already got all of our stuff built in into that or, or to, to whatever tool for security, et cetera.

There are some things that you want, one of, you want one directory or at least a federated set of directories, right? You want one, you want one, uh, I, uh, ID identification or ID management of people, devices, things like that. You want one sign on?

Well, there's a capability to kind of tie those things together across applications, but even those aren't one platform, right? Those are oftentimes things that are tied together. Uh, I don't, I don't know if I agree.

I, I think, I think the single platforms of Kyra, I think that that being able to manage ad plus jump cloud plus whatever in one place is both possible and desirable. It's just when you start, like you, when you start to add more and more things that you're all seeing in one place, like you say e even if you succeed innovation, you know, uh, uh, put puts that at a date, but yeah. Yeah.

But I, I think, I don't think it's settling on. I mean, that's one approach, the single source approach, settle on one directory, just stick with that. Um, but also, uh, being able to, uh, add or use other, um, other directories and, and, you know, uh, identity systems while still not, without having to add a separate way to, to operate them.

That's more the goal here. And I just wanna open up an issue in GitHub so my platform engineer can set, set my environment up and I don't have to think about the directory. I wanna be served my environment and that's, Yeah, no, I absolutely, well, Is important talk.

Doesn't that go back to the, or like when I first got involved in tech, that was the mantra of it. Our customers are the employees, the developers, and we serve our customers. It's an internal customer changed over the years, but it's still true.

Anyway, guys, we're, we're over time. I gotta pull the plug. Um, what a great Monday back to work week.

You know, I still think we should have a national holiday after the Super Bowl, but, um, we hope you enjoyed the show. We'll be back tomorrow. We've got a ton of great text drunk TV following this today, so check that out.

But until tomorrow, on behalf of the gang, have a great day everyone. We're outta here. This is Textron tv.

Hey everyone, welcome back here to techron tv. I've got a new company to talk to you about. They haven't been on our show before and it's the first time guest, I just met him, his, let me introduce you all to Chaz Ballou.

Chaz is the CEO of a company called Conveyor. Hey Chaz, how are you today? Hey, Alan, good morning.

Nice to see you. Good morning. Welcome.

So I, I guess let's, before we get into conveyor, and there's a lot we're gonna unpack here, Chaz, let's start a little bit with you though. You're the CEO there. Um, give us a sense of, you know, how you came to be the CEO of this company.

What, what's your journey been like? Yeah, uh, well again, thanks for having me. Um, my journey, I grew up in the Midwest and always knew, uh, you know, just hacking on computers and very typical story, you know, middle class, born in Detroit, grew up in the Chicago suburbs and grew up, you know, playing computer games, then getting interested in programming, then building computers and was just kind of in place, you know, for the early internet.

And that first wave. And I know always knew I wanted to, you know, build a software company and, and make a living in tech to go to college. I really wanted to go to Princeton and run track and cross country there.

And, uh, to make, make that work, I did an ROTC scholarship and signed up and served in the Army for, uh, four years on active duty in Washington, DC For you. For you. Yeah.

Well, thank you. Thank you for your service. Thank you.

Yeah. Um, and it was a, it was a, a very, uh, interesting experience. I, uh, before doing that, I went to law school.

So when I was on active duty, I was a lawyer in the Pentagon working at the Army office of the General Counsel and Jack. I was like, yeah, exactly right. Yeah, that whole world, we were working on the, um, not on like UCMJ or you know, court martials or like Jag stuff.

We were working on army, like Pentagon stuff. Like, you know, what bases go where and how are we doing, um, all kinds of stuff. The particular group that I worked in was anything to do with any land and that the Army controls.

So all, all, you know, all kinds of stuff from basing and what bases are opening and closing to what can you do on a firing range to what, you know, how do we build new, uh, bases or how do we tear down old stuff? Like, you know, you could have all kinds of stuff, housing base, typical base stuff, but you could also have weapons, munitions, explosives, if the army has a bunch of stuff that's like beyond normal, uh, real Estate. Yeah, no, it's not your usual land use kind of zoning.

Yeah. You know what I mean? And we also had Commercial or residential.

Yeah, yeah. And we also had, the Army also runs, um, the Army Corps of Engineers. So we had a ton of stuff related to, uh, army Corps including, I mean, everything from Katrina and the Katrina litigation that was a a trillion dollar combined litigation, stuff like that to, um, you know, when there's a flood and the Army Corps of Engineers decides or decides not to blow a levee and flood a, you know, flood a field or stuff like that, that all gets turned into, uh, takings claims, constitutional claims and, you know, claims for, hey, let's, um, let's get domain and stuff like that.

Yep, exactly. Yeah. So we, I mean, I, I could, I could tell you all war stories for hours about all the interesting weird stuff.

Um, but that was, uh, for four years and the whole time I was doing this, thinking, okay, I'm gonna have a whole bunch of interesting experiences and background for when I go start my company and work in technology. And so, um, 2013, I got, I, I had gone to undergrad, gone to law school, served four years in the Army, and I got out and immediately started my first company, uh, company called Adaptable, which was a, we started it, uh, as a secure HIPAA compliant cloud hosting platform that runs on AWS and we sold it to digital, uh, health teams and said, look, this is like HIPAA compliance in a box. And we, we took that through, we did a Y Combinator in 2014 with that and raised a series A and uh, got that profitable, like nicely profitable and good for you.

Yeah. And my co-founder is still running that. And in 2021 we said we had this profitable growing business.

Um, and then also we saw the opportunity for what was going on with Conveyor and what conveyor became, which is trust building or, uh, you know, how do you prove to one of your customers that they should trust your security posture? We saw that at Adaptable in 2021. We said, let's split our bets.

Let's take the profitable company and the hosting thing and get it out, you know, into its own vehicle. And let's take this wild card, which is conveyor this totally, you know, seed stage idea. But really interesting strategically in that what we were seeing was the Adaptable's customer base was small, small companies, startups, and the customer is engineering teams.

'cause they're buying a DevOps platform. And what we started seeing with Conveyor was big companies with big teams and big problems with communication and how they get their story straight. Like our customers, like DocuSign or Workday have thousands of employees.

They have hundreds of people on their sales and security teams. How do they all get their story straight and make it as easy as possible for their customers, which could be big banks, fortune five hundreds to trust 'em. And that is, um, that's still what we're working on with conveyor today.

Uh, so that's a, a bit of what a great story. Yeah. My background, how we, you know, I'm, I'm a basically the two time, you know, software founder here and conveyor is the latest iteration.

I think the, I mean, that brings us up to AI today and what's going on today, which is just that we started conveyor in 2021 working on a lot of it was like Salesforce automation and automating, getting an NDA signed and automating, getting customers secure documents. Like, oh, you have a SOC two report or a pen test report, or, you know, like collateral that your sales team has been given. And then you gotta get that to customers.

But it also, it's gotta be secure, it's gotta be authenticated. You want sometimes, uh, you know, like timestamps and water watermarks and you know, hey, confidential, don't distribute this type of stuff on the documents. So we started, um, with all of that in 2021.

And then, yeah, just what is happening with deep learning and AI has come in like a freight train and it's getting stronger. You know, the rate of change and the rate of capabilities increase is really astounding. And we, we started in 2022 using, uh, AI to do rag flows and fill out paperwork and say, okay, so you got, you know, you got a security form from your Fortune 500 customer.

It's 300 questions long. It's all embedded in this Excel sheet. We started making software to go and do retrieval, augmented generation, look at a knowledge base or your database, and then draft new answers.

And getting that right has been really fun, really rewarding, difficult technically, but also pays off in huge ways for our customers. So our customers are very large companies with complex knowledge graphs, lots of products, lots of, you know, variables to keep straight. 7 on average.

7% of the time. Like first pass is perfectly accurate. Like, it's like put it to bad accuracy, which is given how security, like, there's a lot of sometimes, uh, bonkers questions or a long tail.

So 95 is actually approaching per, like, as as good as you can get. We think about 97 is about 3% of questions are just on average gonna be kind of off the wall. Like you, you won't really be able to like fully predict 'em.

And so as you get to like 97% automation, you start, you know, that's like as good as you're going to get. That's bad, certainly superhuman. Absolutely.

com days. And, um, we were doing hosted Oracle and PeopleSoft and all these old applications before there was cloud, before you had multi-tenant, all that stuff. And we used to think if you got to 80, 85% it was super humid.

Mm-hmm. Right? The other 15% is always just craziness, quite frankly, right?

It, it, it's total one-offs. Just total one-offs. Right?

And so, you know, anything over 85 97 is, is ridiculous. It just ridiculous. So let me ask you one quick question though.

So did you run track at Princeton? I did, yeah. Yep.

Good For You, man. And 5K and, yeah, Very cool. What a great story.

What a great story and what a great lead into conveyor and, and, and what you're doing now. As you mentioned ai, I mean, the whole business process automation and low code, no code. And so many other things are being disrupted here, but whether, you know, sometimes it's better to be lucky than smart, but whether it was luck or, or being smart, you find your play, you find yourselves in a place where agentic AI actually is gonna help you because it, it's kind of what you're doing.

Before there was ai, before there was agents, now you can really accelerate that through the use of AI agents, correct? Yeah. So we look and we were talking, you know, warming up, we were talking a lot about, about this.

com today and go to our website and look at our use cases, you'll see that we're marketed as automating security reviews and security questionnaires. And we're really targeted towards that. And all the time we get asked, will you do RFPs too, or RFIs or, you know, how are you gonna handle that?

And that's a big part of what we're doing this year is expanding, um, those, you know, use cases. But fundamentally what it really is is automation. It's workflow automation, and it's a specific kind of workflow.

The specific kind is the, when your customers need answers to sometimes technical, sometimes legal, sometimes compliance questions, and they're putting it on their paper and they're saying, Hey, I need your answers to this. I need you to basically ver you know, attest to the answers to these. Sometimes that gets pulled in explicitly like into an MSA where they say, okay, here's the security appendix and you promise that, you know, it's a violation of our contract.

Or sometimes they're just sent in procurement and there's no explicit attestation that, hey, this is part of the contract. But oftentimes these things have, um, the, the stakes matter, like the answers need to be correct in a way where with a lot of internal tools, AI doesn't need to be a hundred percent correct. 'cause you're gonna have a human who looks at it and is like, okay, well thanks.

And then decides what to respond to the customer. But the kind of software that we're building, the goal you mentioned, you mentioned like, you know, what are we doing is to fully automate all of the work that your customer needs to buy you for these, you know, clear you as a vendor for these kinds of processes. And a big part of that is when they have a form for you to fill out, filling out the form and getting really high performance on that.

But a much bigger part of that work is all of what our customers call, like, the stupid work around filling out the form. So it's what happens before you fill out the form, which is, you know, the sales team sends over five different documents and only one of 'em is a security questionnaire. And they said that there were two things for you.

You know, like stuff like that. It's like, wait a minute now you gotta go back to the sales person and figure out what's going on here. That kind of stuff.

So you haven't even gotten to the point where you're gonna use AI to blast through one of these forms. You're just doing the stupid work around coordinating or AI comes back and it's like, well, we don't have answers. Well, who do you talk to?

Well, what kind of questions are they? Oh, it's product questions. Now we gotta track down somebody in product management, right?

And like, get the answers or figure out have things changed, all of that. Do you see what I mean? Like, that's all the work around, even if you have a, a magic rag tool or a really great, you know, form filler like we do, there's still so much other work around that form filling, getting ready for it, figuring out what happens and how you, you know, how you complete the whole thing.

And that's what makes Agen AI so exciting. And that's also what makes, because it 'cause what we can do and what's working is you take all of that stupid work and you really break it down. You really break it down into excruciating detail.

You really, you blow it apart into literally like a thousand different pieces. And they're, you know, they're organized by each of these. Each of these parts of stupid work can sometimes involve a bunch of different decisions, but you can really break down the decisions and then you can build code and AI working together like scaffolding and calls to models that together can process this cognitive architecture or this decision making flow.

But using AI to go through and do it and breaking it down gets you really good results versus one trying to one shot everything in a big prompt and say, you know, hey, like, here's a bunch of context. Get the answer right or, um, make a decision. So anyways, that's kind of getting into the weeds around how to get good results out of this.

But the big news is it works. It really works, which is incredible. This is software that's never been possible to build.

You can never build software before that makes good decisions not for you. I mean, look wild. I've known, I I person cha I've personally known at least three different entrepreneurs who over the last, let's say 20 years have tried to, you know, using BPA kind of stuff, have form fillers, if you will Yeah.

In different ones. I've seen 'em in real estate, in medical, uh, in, uh, or one of my friends actually created the first mortgage application that you didn't have humans involved in. Right?

That was pretty cool. Um, but, you know, the whole AI agent, AI potential to just really disrupt this whole thing is, is crazy. But you said something early on that I wanna come back to as we, you know, round out our time here.

And that is, all of this stuff is the means to the end, but the end is building trust between you and your customer. And I don't mean conveyor and conveyor's customer though, that's part of it. But, you know, the, the people who are using conveyor, it's their companies building trust with their customers.

Because at the end of the day, that kind of makes the world go round and round. Yeah. It's essential.

And we see it with, you know, security reviews and building that kind of trust. But we also see our software being used for RFPs and RFIs and other types of trust. Like we started, I I, I mentioned this briefly before, but we, um, we started seeing manufacturing companies and agriculture companies.

We have a freight forwarder, a logistics, like a shipping, uh, a trucking company, basically using our software. And they're getting basically these, again, these forms they had to fill out. Sometimes they're called RFPs, RFIs, sometimes they're called quality management questionnaires.

com is still very much, Hey, this is designed for security compliance automation. But what we're, what we're seeing is that the underlying technology to represent the data involved in an organization with multiple products, a bunch of different, you know, usually dozens of people on the sales team, a dozen people on the security team, several different people on product and engineering. Uh, Workday is our customer.

They have 12 different product lines across three different subsidiaries. So being able to take all of that complexity and wrangle it really well is the foundation for getting good results with ai. And that's what our, that's what people are seeing when they're trying this out for quality management or RFPs or RFIs.

What they're seeing is the hard parts are processing bad file formats, right? And import and export out of Word and PDF and stuff. Or like you were saying, um, form filling, like being able to go headlessly and go to fill, you know, get a form and, uh, you know, ultimately fill it out with no human involved at and make sure it's accurate and that, you know, all of that stuff.

Um, those are all, you know, those are all tools, but like you were saying, for our, our customers, what their, what their ideal state would be, anytime any customer has anything that they need in any format, if they need docs, if they need a form filled out, if they need whatever, they can go to this system called conveyor, right? But their customer doesn't need to know that. com or, you know, Workday, the workday, uh, customer, um, you know, compliance portal or whatever they wanna call it.

But they can go to the system and their customers either through, if they need like documents, they can get documents. But if they need anything with ai, it's gonna be secure. Like, they're gonna authenticate to the ai, the AI will be able to talk, pull up their Salesforce record, just like talking with a human.

We'll be able to say, Hey, gimme any form, any questions, anything you need filled out, and I'll be able to get it back to you in a few minutes here. Like, complete, complete automation of this kind of, yeah. Like trust, trust building, not just around security.

You know, today a lot of our marketing, like I said, is focused on security, but what it really is, is anything that the business is gonna be making these kinds of representations to, so it it includes helping automate RFP and RFI stuff. You know, like I said, you know, companies that have promises to their customers that, you know, ultimately get ended, it ends up being like compliance paperwork, right? Your customer sends you something and they say, Hey, you have to attest whether you comply.

But like for, um, for some of these manufacturing companies, they're not making software and the questions aren't about digital security. They're making precision manufacturing machines, or, uh, they're making potatoes or they're making logistics like freight, you know, shipping. And they are still, what they wanna be able to do is achieve that dream where they have a system, everything, all the knowledge is in the system, and then customers just get instantly, anytime, whenever they need it.

Perfect. Trust building. Perfect.

You know, and that it's like not just a form filling, but anything they need, any answers, oh, one-off questions, like, here, here you go, on demand instantly at scale. That's the dream for them. And so ai, all the AI stuff and the various products, and we have a, uh, uh, agentic customer trust intake agent today, we're launching an RFP agent, uh, next week.

Uh, you know, like all of that future is still just trying to serve the dream of perfect instant, you know, high quality trust building, you know, ONTAP, anytime. Well, the, it ja we're way over time. Yeah.

I gotta pull the plug on this one, but, hey, no worries. Thanks for coming on here and, and getting us smart on conveyor. It's a gr look, this is a great story.

They'll make a movie of it one day, but, um, you know, keep up the great work. We'd love to hear you as ag agentic ai. 'cause look, that's still in itself fairly new, right?

As this continues to develop, though, we'd love to have you back on and talk about how it's kind of taken you to the next level here, or allowing your customers to build trust with their customers. Yeah. And as I, you know, we didn't talk about this, but as you have not just one agent, but multiple agents, how do you oversee them?

How do you manage them? How do you deal with quality? How do you deal with engine Orchestration Errors and exception handling, you know, all of this.

And yeah. The ton of, a ton of really interesting stuff to go into That. It's interesting times for sure, my friend.

Yeah. All right. All right.

Chad Belu, C Chad Belu, CEO of conveyor here on Text Drunk tv. We're gonna take a break. We'll be back with more.

Hello and welcome to the Techstrong AI podcast. I'm Amanda Ani. I'm excited to be here today with Greg Whalen.

He is the CTO of Prove ai. How are you doing today? I'm great, how are you?

Thanks for having me. Happy to have you on the show. Can you share a little bit about prove AI and then some of your experience?

Yes, absolutely. So, at Prove ai, our mission is to de-risk the development of ai, right? And specifically right now, we mean generative AI and LLMs, right?

So the, the problem we're reacting to, um, you know, that we're hearing from customers, right? Is that, um, there's a lot of organizations are just getting started with, with ai, right? Developments, they're starting to figure out, um, okay, they built something useful.

Now let's start putting this into production, right? Let's start using this thing, right? Like, like any other sort of software in the past, this raises questions, right?

And, um, since AI is a very different animal, AI development is a different animal than traditional software. What, what, what we're seeing is that traditional approaches to risk management and to, right? The, you know, the types of things you need to worry about when you deploy software are different, right?

And they're starting to confuse people and, uh, right, they're starting to put on, you know, the brakes, right? So, prove ai, what we're, what our mission here is to say, let's not repeat the mistakes of the past, right? So when computing paradigms have changed and we found out more productive ways or faster ways to develop software, right?

Let's not make the same mistakes and, uh, just continue as a, ignore the problems, right? And then find out later on that uhoh, we're gonna have to redo everything, right? We have to reinvestigate our approach to risk management, and this, that, right?

Because it just slows everything down. People get annoyed, and, you know, those who are better prepared for it will leapfrog and be able to be the market leaders, right? First in market.

So, right. Our software is specifically designed to help customers through those types of, um, challenges by basically preparing themselves more long term for doing AI developments, um, you know, at scale, which we think everybody's gonna have to do, um, given the importance of it. Absolutely.

And I imagine, you know, having to backtrack, not only is it a waste of time and energy, but probably a financial strain as well. Absolutely. Absolutely.

So, so yes, there's, there's immediate cost ROI here that comes down to time and productivity, right? So in addition to, to mitigating risks and things like that, right? Even if you sort of say, well, we don't know what the risks are yet, because we're still so early in the journey Yeah.

That that's true. But imagine the costs, the financial costs you're going to have by, by basically furloughing, you know, many developers for, and, and introducing processes that worked for cloud, you know, cloud development or web two development that don't particularly work well for AI development, right? The costs are very big.

By then, you'll have teams of people working on this, probably relatively highly compensated teams, right? And basically, by, by making it such that they can't spend every waking day developing software is lost money, right? And, you know, we think that there's returns by investing in this now, so you never have to get into that state to begin with.

So from your experience working with different clients, what are some of the biggest risks or problems that you've seen them encounter? And what advice do you have to avoid those risks? Yeah, So think that, that the biggest, the biggest risk or the biggest, uh, you know, problem that we can solve at the high level, it's a business problem.

It's not really a risk, it's, it's, it's understanding like, and communicating what our mutual obligations are between multiple departments or multiple, you know, parties. So it's the breakdown in communication between those multiple parties. That's the biggest risk.

So it's like, I, I say that for instance, let's take a very practical example around data assets and data usage, right? So me as a vendor, I have a solution. It maybe it's a, maybe it's a great solution and, uh, maybe it uses, um, some sort of AI behind the scenes.

Um, you know, and, and maybe I wanna be sure to somebody who buys the solution around what sort of data assets it's using right behind the scenes. So I want assurance that every time that you change something, you're gonna guarantee to me that you're, you're, you're applying the same ethical standards, the same kind of legal standards that, that I need to make sure that I can keep using, you know, your software, because I don't know what sort of training data is actually being used behind the scenes for your solution, right? So you have very practical problem in the old world, right?

We would've maybe just signed some sort of contract or something like that, that says, Hey, you're not gonna do thing X that I don't want you to do. Or you would, you would establish an SLA that establishes uptime and availability and error rates, and establishes what we're going to do when we breach those types of things. Uh, the, the problem in today's world is that doesn't, the problem in the AI world is that doesn't work particularly well anymore, right?

Even because the, the sense of what's, what's good and what's bad, or what, you know, what you can do, and what you can't do is so blurry that unless you're really in the details, right down to the level of exactly what data is being used, by whom, by where, where's the model running, then, then the whole, the whole discussion around mutual obligations is pointless to begin with because it's, it's impossible to write in just standard right? Contractual terms anymore. So, so like, you know, the, the biggest, like, problem number one is simply expressing, right, what we actually expect of each other.

And, um, for proof ai, right? We do this in the form of modules, software modules, right? That allow you to concisely and clearly in, in code, of course, right?

So this is this, it still has to be translated to code. Like, you know, let's get into the details of your data sets, which detail, which data sets are we talking about? Which models are we talking about specifically who owns them, right?

And now let's, let's track the events from those particular, you know, from the systems that manage those. And let's, let's talk about and define what's good and what's bad, right? What's acceptable, what's not acceptable.

And when things start to go unacceptable, I wanna be notified in real time as a customer that, hey, we're in a potential breach so that we don't have to have a big complicated, you know, discussion about it, right? Did we or did we not? Right?

It's, it's simply a, this was the model we were talking about. These were the data sets we were talking about. This is what we said we would do on update.

Are we doing those things? Are we not? Right?

It's a much more practical discussion, right, to have than than others. So I'll answer it that way, right? I think the biggest discussion is there, there's sort of this fear of, okay, I wanna use this solution, but I really have no idea what it's doing behind the scenes.

And then, okay, I, I want to address that problem, right? I wanna have a discussion about it, but the discussion is unruly because it's so difficult to be specific, right? And, and, and, um, yeah, that's actually the, the first problem that we think is gonna su we'd like to solve, because that's what gets in the way of, of doing anything right now.

It's just, uh, you know, I'm, I'm a customer, I'm worried I want assurances. Um, I know what assurances I want at a high level. I don't know how to define it and I don't know how to track it.

So, you know, you can start there. That's one of the first, you know, problems to, you know, to start with. Absolutely.

And so, I know there's a lot of, um, new regulations and AI laws, uh, in fact a few introduced by the eu. Uh, how do companies need to, um, address and, and, um, adhere to these new laws and regulations and stay on top of those? Yep.

Yep. So, um, we think that at least my, my personal take is somebody with a technical background here, right? So I don't have a compliance background, right?

But, but of course, over the, the past many decades, right? Have, having been through many compliance waves, right? I think that the best way to stay on top of things is to, you know, approach these things.

As you know, compliance is basically the bare minimum, right? So, like, whatever's going on in compliance is very, very much worth your time to look at today, right? Figure out, hey, you know, if, if I had to comply with this tomorrow, could I, because even if you don't, it's still a very good thought exercise, right?

Around where would I have to start? Because generally, compliances are not, you know, they don't fully tell you how to manage risk in your organization, right? They're very much a sort of baseline standard about, Hey, let's be sensible.

You should at least be doing these things, right? So in general, my my take is that you, you don't wanna be caught sideways in another year when you find out you have to comply with something, right? That's the, that's the way that people have often, you know, said, oh, we don't need to worry about that IO standard yet, because it's not a law, right?

So let's just wait. Um, okay. But then when something does happen, even if it's not ISO, it's something similar to an ISO standard, and then you probably could have been, you probably would've saved yourself a lot of pain if you had just said, yeah, let's, let's read the standard and let's, let's make sure we could roughly comply with it now, because that's gonna probably be a pretty good, you know, framework and platform to start with, to actually manage risk in my ai.

So you, in summary, I, I think it's, uh, you, regardless of when they're going to become required, or whether they're considered sufficient to transmit to other parties that, Hey, I'm doing what's, what's legally required, even if that never happens, the point is, a lot of people started and put a, a lot of smart people put a lot of thought into the AI ISO standards that really it's worth looking at and saying, maybe I should just start there, and maybe that's a good, you know, starting place. And then let's build on it to figure out like, what do I have to do extra to really manage, you know, risk of AI development, either with my partners or internally. So still very much recommended that you start, you know, looking at it as a baseline just because, you know, where else are you going to get an, you know, an output from many people who are very experienced in the, you know, in the field telling you that, Hey, this is probably a pretty common thing everybody should be doing, right?

It's, it's, it's worth doing now so you're not caught unaware in another year, right? And yeah, even if it's not law, somebody's gonna ask you those same questions because they're very much a baseline, right? None of these things are outlandish, crazy things to do.

They're, they're, they're very much a, a, a bare minimum in many cases, right? So why not, why not start? Now?

I understand many business leaders have concern with budgets when it comes to integrating new AI tools, uh, to solve problems, and they're looking for that return on investment. So what advice do you have for them? Yeah.

Do, do, I guess, would you mean for like a compliance tool or actually just for an investment in ai, It, um, investment in AI or compliance tools? Um, I'd like your opinion on it. Sure, Sure.

So for, I mean, I, I think most of the investment, we, at least from a compliance tool, right? We wanna see that the investment is tied to the actual solution, right? So, right.

That they believe enough in AI that in their AI project, that they know exactly what they're going to, you know, get out of it. So, like, if you're in, if it's a, if it's a relatively common customer support use case, right? We're talking about having a very clear idea that, you know, we want, you know, you know, we wanna automate ticket response, we wanna see, you know, customer happiness increase, we wanna see throughput, and we ultimately want to lower, you know, cost of, um, you know, cost of, you know, cost of serving costs, right?

The cost to serve the customers. Um, I mean, that would be an example. So I, I don't, so I mean, the recommendation would be that, you know, rather than thinking about investment in compliance is separate, I think it's, it's absolutely necessary to just think about what is the actual, you know, return on this, on the AI thing that you're, the ai, ai embedded product that you're working on.

Um, so it's gonna vary wildly by, uh, by use case, right? Customer support is usually error rates decrease, right? Customer, uh, you know, time to serve customers drops, right?

Which is good, right? And the error rates, error rates lower and overall lower labor costs, right? Decrease.

Um, you know, for other things, let's take, you know, the ad tech space, right? And targeting, right? Hey, targeting, you know, microsegmentation gets even more precise, right?

You get to, you know, basically, you know, the, the revenue per customer, rev revenue per person serves, right? Can increase in things like that, right? So it, it varies wildly, right?

But, but usually you're talking about in all of these cases, right? Doing something more quickly than a human being could do. So typically when you're talking about ai, you're talking about doing a task that was traditionally assigned to a human right, was relatively slow, was a relatively, you know, large pain point, right?

And now you're going to eliminate that sort of manual review, uh, you know, not because the human was slow, it just wasn't a task that was, that was scalable towards, you know, towards, um, you know, a human line of thought. So we're saying, you know, we got software up to a point where it was automated, there was a manual check, typically, typically an AI of some sort of replacing, you know, what used to fall back on people, right? So you can imagine the savings is always, you know, better accuracy, you know, at lower cost.

Um, so what, you know, then the return though of a compliance tool like us is to say, okay, but, but, you know, there's a hidden cost here, right? So I think that's our, that's our big cautionary tale here to people deploying ai, is that, um, okay, yes, you're gonna save this money if this AI performs well, unlike a human, right? AI's don't always have, or AI agents or, or whatever, they don't always have co, you know, common sense, what we perceive as common sense, right?

Which means that, you know, you, you might have a very anomalous, unexpected error that has a huge blast radius, right? That's just like, whoa, like a human would've never made this error. So the AI may be like, wow, this thing is, is also, it really does in fact, perform better than human review.

It does a lot faster. But you're going to find these unexpected untestable, undiscoverable, you know, kind of, um, instances where there's just a big problem. It's a high cost, right?

High brand damage, right? It could be a, it could be something is saying, you know, of, of a, a poor refund handling or something like that, where, hey, there's an exploit and, and suddenly your automated solution is starting to give out refunds that really would never have ever happened under human review, right? So there's monetary loss as well.

And we've, we've seen actually, you know, some of these things have actually already happened. Um, you know, so, so we say, okay, well then the return on investment of a compliance tool or of a risk management tool de-risking AI, is to say, yeah, those things are going to happen, right? And right, we're going to prove return on our investment by saying that when they happen, the blast radius is going to be as minimal as possible.

The o the downtime is gonna be as minimal as possible. This is gonna be traceable, right? It's gonna be very clear who messed up, right?

So a lot of companies don't have that today. It's gonna be a discussion when something happens and it will happen. Uh, it's going to be unexpectedly large in some cases, right?

The impact is gonna be, whoa, you know, how did that happen? Uh, that's very damaging. And then it's gonna be who's at fault, right?

How do we fix it? Right? What actually happened and who's at fault?

Um, without having something in place that actually tracked every single thing, every single prediction, and every single stage in the development across multiple organizations, right? Multiple data sets, multiple parties, then you're never gonna be able to get to the bottom of that question, right? It's gonna be a finger pointing match, it's going to be a, well, we need a couple of weeks to dig into the logs and then share logs with each other, right?

Which is a very traditional software development process, right? There was an outage. I want to root cause analysis.

I want an action list of what's you know, of, of how to, how this, uh, how we can never repeat this again. It's not gonna work very well with an AI model, because there, there's no specific list of actions, right? Other than we need to review things manually that you're gonna come up with.

And we've already said earlier that that's the wrong approach, right? Because that doesn't scale either. So, right?

That's what we think the return is. The, the return here is, um, is very much around managing those, those sort of big blast radius anomalies that are inevitable, you know, going to come up and then reducing the amount of time to resolution, reducing the amount of time and effort spent figuring out who did what, right? And then figuring out how we never happen again at a precise level, right?

Where in the chain did this actually fail? So A very helpful tool to have, especially as we see AI being utilized for so many more things and so many more automations. Absolutely.

Yes. All right. Well, if there was one key takeaway you could leave our audience with today, what would that be?

Yeah, so going back to the beginning, I, the key takeaway I think is to get started with, you know, de-risking now, right? So obviously that's, uh, a bit self-serving as you can imagine. But I think it's, uh, it's been the right advice EEO to customers over the many waves of computing, right?

It's, it's, as we started to do cloud development as we did web development, right? Getting, getting ahead of it is going to save your developers and your organization a massive headache by doing just a little bit now so that you're prepared when inevitably a customer asks for something, right? They say, all right, we have, we need to have a risk discussion, right?

Or a regulation is imposed, and you have to go react to it. So, you know, the, the, the, you know, the recommendation here is you're gonna need to move fast, right? Don't wait.

Um, thinking about compliance and risk is actually pretty healthy for an organization now because it allows you to move faster, right? You don't have confusing discussions with leaders and pe right? It forces them to start to get educated now, which is actually better, right?

So to your earlier question about return on investment, right? It's, it's probably net positive, right? Even if you don't have a lot of AI now, because at at least it brings everybody to the table to talk in a data-driven way about risks and about specifics of a model, partic, you know, potential pitfalls, right?

In a way that really we've seen a lot of customers have challenges with. Alright, well thank you so much for coming on the show and sharing your insights with us today. Uh, thank you for your time.

I appreciate it. And thank you to our audience. Stay tuned.

There's more. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of security bloggers network. Hey everyone, I'm Alan Shimel. That's Luca gte and you are watching the Platform Engineering Show.

Hey, Luca, happy New Year. It's great to see you, my friend. How are you?

You too. I'm good. How are you doing?

Happy New Year. Happy year everybody. Yeah.

Happy New Year to everyone. So, Luca, where let's play. Where's Luca?

Where in the world are you today? Man, East coast is Sri Lanka, The east coast of Sri Lanka. That's great.

And it's nice and warm there. You're on the beach. Yeah, I apparently tour than in Florida, right?

Yeah. Well, winter, winter came to Florida, right? But we get this around this time of year, we'll get like three, four days.

I was telling you where it, sometimes it'll go down even into the high thirties, low forties, fa night. And then the, the, uh, the iguanas that are, they're not native, but they're invasive here. They, they get frozen up in the palm trees and they go what they call topi, like, you know, they just shut down and then they fall outta trees.

And some of these iguanas are like four feet to, I mean, they're big, they're big reptiles, so you don't want 'em falling on your head. Y'all get hurt. But, um, this is So fascinating to me.

It's crazy. It's crazy. But, but, but do they recover or are they dead?

Um, it depends how long and how cold they are. How long, because you know what Gus are usually like that nice green color, and then when they're in reading colors, they get red and orange. When they get topi like that, they turn gray.

It's like they really Yeah. It's a good dark. They look like off.

Yeah. Um, crazy. But yeah, we'll see.

I mean, no, they're, they're kind of like a nuisance animal here. So people aren't terribly upset that some iguanas die. Uh, they don't belong here and they just, they're a mess.

They're a mess. Right. Anyway, enough about iguanas.

You're in Sri Lanka. There's a lot going on in the world of platform engineering, though. We got a great topic to cover today.

But before we do, I wanted to just go over with you a few things. First of all, we're making plans here to head over to London, the cube con, I think it's April 1st to the fourth is the actual cube con. Um, but I know the community has, has some real big plans going on.

You wanna share A little? Yeah, it's gonna be, it's gonna be a big one. Um, CubeCon, right?

In London, they're expecting 12,000 people. And so we do our sort of like unofficial CubeCon opening party, which is Coha Cube. We've been doing it now for like two or three years.

It grows every time, expecting a lot of people. Probably like 4,000 plus signups. There's probably gonna be like 500 people, 600 people at the location.

It'll be crazy. And, and you know, the whole thing about cubes, like we started it when I think we were at CubeCon Valencia, and it was basically, oh, I love That. We were kind of going from like, which was great 'cause it was like Valencia and so on, but we were basically going from like one party to the next, or like, man, all these parties are the same.

Um, and obviously, you know, we have like a Berlin background, uh, techno background. So we were kind of like, wouldn't it be funny to do the sort of like, uh, the dark room of DevOps? Um, and for those that catch the reference.

Um, and, and, and so it's hard like, as, as a joke, but we did it. Um, and it's really funny 'cause it's always, there's a bit bit of a tension with the CNCF guidelines that basically don't allow you to sing in the dark room of DevOps. Um, but yeah, so we started and, and, and now it grew to basically really become the unofficial opening party.

You know, we have like drag queen shows and it's a whole thing. So, so that's gonna be really fun. Really.

Oh, Very cool. Um, yeah, yeah, yeah. Looking forward to that one.

Kind of Like Key West Yeah. Down here. We, that's, I dunno if you've ever been down to Key West, but they lot of that.

No, but I heard, yeah. Um, yeah, Yeah, it is. Yeah.

Well, you are other places that are more, but anyway, um, I digress. Let, where can people get more information about House Cube? com.

Um, and you could sign up. It's free. We have, uh, amazing food, amazing drinks, amazing drag queens.

So just come for fun post party. We're gonna do that. That's fun.

That sounds great. And then the other, you know, big thing on the horizon, and it's not too early to get this out there, is, this is the third or fourth platform con This is coming up in June, this fourth platform con So we started 22. Yeah.

Um, we had like, I think like 6,000 people or so joining virtually. Um, then we have poverty from Country three. We had like 20,000, uh, 24 last year.

We had like 35,000 or something. And then expecting like over 40,000, um, this year. But the important thing this year is that we're really doubling down on the in-person components.

So we're gonna have two live days. One in London, one in New York, both around like four or 500 people. Uh, you know, we have great speakers, Nikki Wat, Gregor Hope, Kelsey Hightower speaking, uh, these things live.

So really excited about that. It's gonna be last week of June. So London on the 25th of June.

And, uh, New York on the 26th of June. Uh, so it's gonna be fun to like hop between one city and the next. Um, but the, I think the events are gonna be great.

We're gonna have parties. We, we have like a lot of great like, speakers live trainings, a lot of new formats that we're rolling out for this. Um, and people can already sign up, platform com, dot com, um, and you can choose your, uh, 'cause your own adventure, uh, and join us either virtually or in person London and New York.

I think Techstrong TV will be in New York. I'd love to come home to New York. Um, and we'll be broadcasting live from there as well.

Yes. So it should be a fun, fun, fun thing. com.

Yeah. Right. Fantastic.

Uh, speakers are, uh, all speakers have been assigned. What about sponsorships available? Yeah, sponsorship's still available.

Um, almost sold out of New York. Um, that, that's gone pretty quickly. Um, and, and you know, we're closed with London, but there's still, there's, there's a lot of like, you know, um, so's like, also virtual sponsorships are still open.

Sure. Um, so anyway, sponsor sponsorship's still open. Um, and there's a lot of like, interesting formats that, as I said, we rolled out the trainings, but also, you know, we're gonna do live interviews with you in New York, for example.

So lots of new interesting things that I think can be very fun as well to do with, uh, with vendors and other sponsors. Very cool. Very cool.

Alright, Luca, we gotta talk about what we're talking about. You know, this is, uh, our third episode. Yep.

This is our third episode. This'll probably be the last one where it's just you and I talk and like this. Well, we gotta bring in some fresh blood, some expertise, and, you know, we'll announce, uh, check marks is gonna sponsor our show.

So many thanks to them for that. We're looking at other sponsors if, if anyone out there might be interested. Um, but for today, Luca, we're gonna talk about platform as a product.

And look in today's world, right, there's platform as a product because everything is as a service, right? So here we got PAAP, and I'm sure the next thing will be PAAS, but you know, what does it actually mean when we talk about platform as a product? And, you know, it's a, it's a key part of this platform engineering kind of mindset.

But, you know, you're the expert. Why don't you define it? Yeah, absolutely.

And, and I actually think it's a good place to start from the PAAS that you mentioned, right? So like the, the platform as a service, right? This is just as kind of like, uh, one of sort of the, the main trends.

If you look back like 15, 20 years ago and like Heroku, all those guys. Heroku store. Yeah.

And Yeah, and, and, and, and it was just said, yeah, like, Hey, like don't worry about anything, right? Like, we, we build this like platform layer for you. It's, you know, it's like turnkey, plug and play, let's go.

Um, and, and that didn't really scale to the enterprise, right? Because like everybody realized, hey, you actually need, um, you know, some, some customized platform layer, uh, for your, for your own enterprise engineer organization. And, and that's kind of what platform engineering, sort of like, you know, where we should like platform, platform as a service or pass ends and, and sort of like platform engineering starts is really this idea of like, hey, you're building this internal product or internal consumption, right?

Like your internal customers are the, um, the, your, your application developers. Uh, and you do that as a product, right? And that's like a very, um, it's probably, in my opinion, the key concept, um, the key foundational concept of platform engineering and also the key differentiator, um, you know, of platform engineers vis-a-vis, let's say like a DOS engineer or, you know, an SRE, um, that, that normally we'd approach infrastructure project as a kind of like one and done, you know, six months project, something of that kind.

Whereas a platform engineer, at least like a, like a good one, um, approaches building an internal developer platform or IDP, which is the end product of a platform engineering initiative as a product, right? So a product that has a life cycle, not that it's, it's not like a one and done, you know, six months thing, but it's actually, it's being rolled out as a minimal viable platform initially, um, for the first few months and then iterate on and then eventually grows. Um, it gets adopted widely across the engineer organization.

Um, right? And, and it keeps being worked on as a product. Uh, and I think it's, it's a, it's a super interesting concept because the moment you look at your internal developer platform as a product, you immediately unlock, you know, 20, 30 years of product management best practices and experience that that we have in the industry that can be applied to build, uh, urinary valve often as a product, Right?

And, and here, here's the thing, whenever you talk about something as a product, the next logical conclusion is who's the customer, right? Right. And, and, and traditionally that was in it, right?

In the IT department going back, I'm going back now, you know, 25, 30 years. The IT department, the, the customer was the internal business, right? It wasn't sort of forward external facing, it was internal Right.

Facing. Right, Right. And, and your customer was the, was the sales guy, the business guy, the marketing person, the HR department, you know, all, all of the above.

It serviced them. It, you know, they, they were the customer of the IT department. So this, I mean, this is not new in terms of a concept of of of that internal customer that gets served, you know, uh, in this case with, with the platform.

The other thing I'll tell you is, look, you know, when, when cloud first came out, a lot of people were very definitive about saying, well, this is infrastructure as a service, IAS, right? And we're gonna have platform as a service, right? And, and haruku was probably the biggest success coming out of that.

But really to a lot of people that meant, well, infrastructure service ended at kind of the hypervisor. They took care of everything hypervisor and below, and you built on top of the hypervisor os and everything else in IT platform as a service initially to a lot of people was, well, no, everything up through the os. And then you just build your app on top of the os.

And I'll tell you my 2 cents on it, if it wasn't for platform as a service not being sort of a complete, uh, concept, you never would've had cloud native. I think what we see as cloud native today with the containers and, and cobe and mesh and everything, you know, that old cloud native stack is a better platform as a service or as a result of the initial like, Heroku style platform as a service just not being complete enough, right? It wasn't what we need.

And then, so now you got this cloud native stack, and now you have this whole platform engineering kinda movement, right? Which is borrowing from a lot of what, what's gone on here. And that's the modern platform as a product platform, as a service that I think people were really thinking about back when, but the initial like Haruku versions were, I don't wanna say flawed, but incomplete.

They were immature, right? Yeah. And, and so I, I think there, dude mm-hmm.

There were like a child Of, no, that's my 2 cents Of the, of its time, right? Of, of like, yeah. Also, like I think stacks that were like a lot simpler, right?

Infrastructure mm-hmm. That were a lot simpler. And, and, but then to your point, right, as cloud native exploded as this like complexity really, um, really exploded as well, then you had to have like a completely different approach.

So it's like the idea is, hey, I still wanna provide a po a path like experience to my developers, right? Um, and, and, and, and I think like you're, you're, uh, priority is super interesting, right? Like, it's also not only the complexity of the infrastructure exploded, but also the, uh, size of the engineer organization exploded to the point where now you have a part of the engineer organization, the serving the other part of the engineer organization at as its internal customers and no longer just like the sales, marketing, hr, whatever, right?

The other functions. And so, and there is also like a, there's also like a, like a mind mindset shift that that needs to happen a lot of times where it's like, well, actually the internal customers is the developer itself, right? Um, which is something that a lot of people are not used to because they think, well, developers kind of build stuff for themselves.

Well, but the, the problem is like once you have, you know, 10,000 developers, then you actually need somebody that likes specifically build stuff for them, right? So, um, but yeah, so the idea is really like, Hey, I want to build a past like, experience for developers, but on top of, you know, a complex and changing and, and, you know, cloud native or hybrid tool chain. Um, and so therefore, I, you know, I, I, I need to take, you know, the, the vision is the same.

I take the tool set, um, you know, in the toolbox of, you know, I borrow it from, from, from kind of like all this other like adjacent disciplines. Um, and then really like, I focus with this like, product mindset on, on building this like, um, so like, platform layer developer, um, DevX, uh, layer on top of this increasingly complex, uh, stack, right? Absolutely.

Hey, you mentioned DevX. I just wanna give a quick shout out. We're gonna do our first live round table of the platform engineering show, um, I think earlier in February.

And it's on DevX. So if DevX is something you guys are interested in, your folks are interested in, uh, stay tuned. We've got a live one where you can take part and ask questions, and we're gonna dive into that.

Now, Luca, the, the platform is a product idea. You know, it's been percolating now for a couple of years, and we're starting to see, I don't know if I want to call it best practices yet, or, you know, evolving best practices. I don't know if it's written in stone everything just yet, but we're starting to certainly see where, hey, this works.

This is not such a good idea. This is a better way of doing that. You know, we're evolving best practices.

Can you talk a little bit about what some of these are and, and where people can kind of, you know, stay in the know on that? Yeah, absolutely. I think like, um, you know, and as I mentioned, like, I think what's interesting is the moment you treat your pop your internal product, your internal platform as a product, you unlock all this like best practice.

Like, so it's not like you need to invent anything radically new. It's like, hey, there is this minimum viable product MVP concept, it's just being rebranded to minimum viable platform, which is the same exact ladders. Um, and the concept is the same.

It's like, Hey, start small, irate quickly, and so on. Um, I'll cover, I'll, I'll talk about MVP in a second. The, but, but I think like before that even, um, like if we look, I think chronologically, and I've seen the, the space sort of like mature in the last couple of years, you know, initially it was kind of like, okay, like what is platform engineering?

Is this helpful for me now? It's like a lot of people are like really bought in to the concept. Like it's been, you know, like crazy.

And we spoke about the, you know, the overall like, you know, numbers about platform engineering as a trend broadly in the other episodes. Um, but you know, with that, a lot of people are coming in, they're like, okay, you know, I'm bought in. I heard this is cool.

Where do I start? Right? Like, what does this thing actually look like and how do I make sense of this?

You know? Yes. We have like a, like a crazy, like cloud native and so landscape, which you can just see the CCF landscape is insane.

Like nobody can actually really understand it, but, um, but even the s of engineering, it makes a good picture. It makes very good picture. Exactly.

Um, and, and, but even the possible engineering landscape at this point has been developing so much that, you know, it's far from that level of complexity. But you know, you already have, like, if you're a newcomer in, and it's like, okay, like how do I, you know, how do I actually piece all this, this from, you know, pieces of the puzzle together for a platform that actually works for me that makes sense for my engineering organization, right? And so that's where I think the first sort of like, standard that's been really, really helpful in a game changer.

I think in the, in the community and, and broadly in the platform engineering market has been this, this reference architectures for interior developer platforms, right? Um, and, and some of the first ones were, um, open source, uh, by McKinsey actually. Um, and then, you know, kind of like, now they're like really widely adopted.

Um, I have one stat for you on that, which is Rincon. Um, they were, so the first, the first, uh, reference architecture was, uh, uh, was kind of like presented in the talk at, at Popcorn Con 23. Um, and so there was only one at Popcorn Con 24 last year.

There were already like 20, 30% of the talks that were using, um, this as a blueprint to kind of like talk through, uh, the platform that practitioners built or whatever, right? So very, very interesting to see like how quickly people adopted this. And it's for a very good reason.

It's just like, it gives like a really good guidance as to like, okay, how do we see, how do you think about the different pieces and how to fit together? org, I think slash tooling or slash platform tooling is, um, you can see the sort of the tooling landscape there. And that also follows the same structure, um, as the, as the reference architecture.

So that was kinda like a first step that was really helpful. But then sort of like, what I've noticed is that people were, um, kind of like looking at this and like, okay, great, that's, that's my target setup. Like, that's how I wanna build my platform.

Um, but then they were trying to do everything, you know, at once. Um, like, you know, the, this, the, the Korean movie, like everything everywhere, all at once. It's kind of like, it's kind of like, like that, right?

Like they were trying to like, okay, like this is great, you know, they get super excited, you know, I get buy in some executives, let's go, you know, build everything. Right? And the problem with that is that, you know, you very, very easily lose momentum, right?

And this is, I think, in my opinion, is the number one cause of death of, apart from engineering initiatives, uh, to be a bit morbid, but it's, um, it's really, it's really like that, right? Like it's, it's people that get really excited that have this like brand designs, um, for, for what the platform is gonna look like. And the problem is that the platform engineer really is a huge, you know, org transformation, right?

And so, uh, and so that means it touches all these different stakeholders, application developers, executives, architects, security teams, infrastructure and operations teams. And so you need to basically get all these people on board with you, you know, sell them effect eternally. This idea of the platform and it's different components that you have like, so beautifully designed in your head.

Um, and, and so the problem is like, it's very easy to lose momentum there, right? Because you need, you know, by the time you, you know, you spoke to person A, B, C by the time you, you spoke to person Z has been six months, person a completely forgot about you. And, you know, you kind of get stuck in this process, right?

And, and there the trick is really to take this minimum viable product or minimum viable platform approach of saying, Hey, start small. Um, focus on like a really, like a subset of, um, uh, not only the problem that you're solving for, for different stakeholders, but actually a, a a subset of the stakeholders, right? So just focus on, on maybe like application developers and security teams or, you know, infrastructure, infrastructure and operations team and executives.

Really, you don't have to please everybody immediately just focus on like, what's the low hanging fruit here? And then if you think about that reference architecture that maybe we can link in the, in the show notes or like throw up a picture at some point, um, we can, you know, you can, you can, you can think of like, well let's, let's actually focus on a subset of events, right? You don't need, you know, your MVP to have a full, um, you know, to be fully security compliant, uh, or, you know, have, uh, you know, the, the latest observability stack built in already.

'cause you, you're not going to production right away with this thing, right? You need to first show the value to, for example, developers and say, Hey, look, you know, Jimmy right now is spending, um, you know, like, um, uh, is is waiting like two weeks every time, uh, he wants, he needs a database, right? Um, and, um, you know, and is providing that.

Um, but you know, now she's like fielding this, like all this like ticket ops request for like 40% of her time. And that sucks, right? And so what you want in the first MVP is, is to actually show, okay, well I, you know, I, I proved the, you know, for example, I reduced the, the, the time that Jimmy needs out for database from like weeks to minutes.

And now Amy only needs to spend like 10 minutes, 10, you know, 10% of her time fielding peaker requests, not like 40, 50%, right? Like, and you know, and you can, you can show that within weeks, right? That's really the powerful thing I've seen, um, like very large enterprises move incredibly fast following this MVP framework, um, and within weeks show some level of success internally to the, the stakeholders they selected.

And then from there it's like, okay, great. Are we all happy? Yes.

Okay, let's go to the next iteration, right? And then of course you should have, like, you should design the end design with, you know, security in mind, for example. But it doesn't mean you need to implement all the latest governance and security workflows from the get-go.

'cause this is gonna slow you down and not gonna get you to actually show value. So, um, I think reference architectures and MVP framework have been, um, very, um, very helpful standards and very helpful best practices that, as I said, you know, we've been borrowing from existing, existing disciplines already, um, and just like slightly tweaked, uh, to, uh, to really help platform teams deliver on their, on their initiatives. Excellent.

Excellent. I mean, Luca, if I, if I had a boiler, it's a bad word to use. 'cause I gonna use that word.

If I had to like just really give people in one line here, right? You, you, you don't wanna boil the ocean with platform as a product you want. You, I you want to do it step by step bit by bit.

Here's my question for you though. Do you need a master plan to begin with saying, okay, here's I, here's step one through six. It may take me three months to do step one, four months to do step two, four months later I'll do step three, but eventually I'll get to steps all the way through to step six.

Or do you just say, well, let's start with step one and then I'll decide what even step two is? 'cause I don't know if I want to make that right. What I'm labeling now is step three may wind up being step two.

Um, right. So I'm not, I'm not locking into any of that. I'm just locking into step one right now.

Totally. I think it, I think it, um, I think it's a mix of both to be honest. org actually has like different tracks.

Like you have an executive track or business track, you have like a technical track, which is basically, you know, how you build everything, how you get the first like developer adoption, you have a security track. How do you make the security team happy, right? And I think like different tracks have different timelines and you need to, right?

So like I think for security and business for example, it is helpful to have a little bit of, you know, like a look into the future, right? Um, and like how do you attach, because you know, for example, like your business, your business stakeholders, like your execs like, you know, usually sink in quarters or even like fiscal years, right? So like how do you attach, you know, your policy engineer initiative to whatever their goal is, for example, for, uh, you know, for the quarter, for the year, um, in some cases multi-year plans, right?

Um, on the developer adoption though, on the other hand, like, it's really what you were saying, um, it, it, it doesn't make sense. Just get started, just get started, figure out, you know, what works, what doesn't, and then I from there, right? So, um, I think there's a combination, and this is also I think where it's helpful to think of your platform as a product.

You know, you know, we've built product, um, uh, products and, you know, the product is not just about building a product, it's also going to market with that product, right? So, um, and so that's where you have, you know, I think you have basically your product engineering teams at a rating very quickly on building a product, especially at the beginning, right? And then as your platform matures, you can have like longer plans and like longer iteration cycles and so on, but at the beginning you want to be very nimble, right?

Um, um, and the same thing kind of like goes for your go-to market at the beginning, you really need to figure out, okay, you know, which executive is gonna support my initiative and so on. But then like over time as it matures, you know, really like attach it to like, you know, very specific budgets or combination of budgets and so on, right? Um, but it, I think it's, it's helpful to, to to, to not only think of like platform as a product, as something that's like purely technical in terms of like, how do I drive developer adoption and how do I, um, you know, you know, iterate re from a product perspective, but really broadly, like if you consider it as a product, it means like it actually needs like its own go to market, uh, its own internal marketing and internal sales effectively.

Um, and actually you can see this, I was, I was talking a, uh, a while back to Aaron Ericsson, who's the guy that that built the, the, the internal developer platform is Salesforce five years past ago. And you know, it's very interesting because, because Salesforce is so big, actually at the time, they had multiple platform initiatives sort of like bubbling up and competing with one another. And so there you have even, and obviously like in, in most organizations you wouldn't have that, right?

Um, but Salesforce, because they're so big, um, but there's some cases of like very large engineering orgs that have, um, similar situations. Um, and, and in that case, really you're competing, right? And you're competing on the product front, but you're also competing on like distribution, right?

On the Platform. Yeah. Yeah.

But I mean, look, you see that in large enterprises that are built through m and a, right? Where you, you have, you know, company A was doing this, company B had that initiative, company C, now they're all under one. com days, right?

We had 30 different acquisitions and each one had their own, you know, not platform per se, but their own it, their own, they were all, they were all storing websites, they were all website hosts. So there was 30 different platforms to coast website side. How do you pick one or eventually you do want to get to one, but it took a really long time because you, you can't, you know, you're gonna wind up breaking some eggs, making that omelet.

And, and, and, and so you, there's a, there's an art to that, right? That's that's a whole thing in and of itself. And, and, and how did you, how did you think about that?

Like how were you Well, we went bankrupt. com, that's bubble, that's, yeah. That made it easy.

I left, but no, but seriously, what we did do is we, we brought in, we, we developed one engineering team across all 30 acquisitions, one engineering team. And they basically took from each of the acquisitions what was best about them, what was the strengths, and then also looked at the wider state of art, right? In the industry.

And, and, and we did, we, we actually built a whole new platform that we migrated these two. Some, some were easy migrations, some were a lot harder migrations. But we built a state of the art.

'cause back then, look, we, we had some companies that were using what I call baker racks, like that you would keep bread on and they would keep white label servers on there. The hard drives are in the server. The server's running Apache and they got a thousand websites on there, right?

Then we had other ones that were running like one U web servers to network attached storage, right? A very different kind of architecture. And we had other ones that, you know, had, would load balancers and st you know, there was, there was a variety of, of, of architecture here.

And, and we settled on one and it took, it took the better part of a year and a half, two years to really migrate into the standard. The company was called inter reliant into the standard inter reliant architecture, which, which by the way back then was like IBM Domino server or something like that. And, you know, it was, it was big enterprise level stuff.

We were hosting a lot of apps. This is before there was cloud, you know, multi-tenancy and all that. And we're hosting Oracle apps and Lotus Notes and, and Exchange and PeopleSoft and, you know, crazy stuff in addition to websites.

So we needed, that's how, actually how I got into security. Then we had Layer security in Checkpoint at the time, was it, and Checkpoint was the big firewall, right? So we had managed checkpoint firewalls in front of this stuff.

It was, it was really cool. 'cause we were way before our time, way, way, way before our time, right? Um, but it was, it wasn't anything like, we didn't have at our fingertips with, you know, platform teams have today, right?

We were inventing this stuff outta rock and chisels, you know, you didn't, you didn't have the tools we have today, but it was interesting. It was Interesting. That's so interesting.

That's so interesting. And, and actually it's something that like, we are seeing a lot in the community as well. Like we do this, uh, this trainings with large enterprises, um, where we kind of like help them either educating their teams or actually like putting together strategy for the rollouts and, you know, phase rollouts and so on.

And I was actually working with like, um, okay, I think it's public right now, but anyway, it's like a very large, maybe the largest I think CPG merger ever. Um, and you know, it, it's kind of like you have these two teams and they, they sort of like are gonna go in, right? It in, in gonna end up in the same setup.

And, and so like one of them wants to figure out, okay, what's the right strategy for me going into this, right? Because I have like something that's working right now, but obviously everything is gonna change. So like how do I, how do I make sure that my platform evolves in a way that it ends up being the winning platform, right?

Uh, from an evolutionary perspective, it's the one actually surviving in the end. So very interesting. These sort of like m and a conversations where you really see this like internal products competing with one another.

Yeah. You also see personalities competing with one another, right? And that, and that's sometimes the personalities are harder than the technologies, right?

And, and, uh, that's a whole nother story. We could talk over beers one day about. Anyway, uh, Luca, there's been a fascinating discussion, man.

I loved it. Um, Yeah, this is fun. org, we've got reference architectures, we've got tools and people and documents out there to help people as we go on, as they set a, you know, set sail on this journey of, of, you know, adopting platform as a product.

Um, wow, what a great show this was. Let, let's can't wait for the next one. Next one.

We'll have some people joining us so it'll be more of a active discussion, but we hope you enjoyed this, Luca, how long you in Sri Lanka? Uh, three more weeks. Yes.

Um, Alright, so maybe for the next show you'll still be there? Um, no, no, no. The next show is in February, so we're gonna Oh, okay.

Yeah. Yeah, because these are almost mid-January. Yeah.

So where, where do you think in the world you might be by then? Japan maybe. I'm, you know what, there's a cube con in Japan in June.

I was really had my eyes on, but we'll see. Yeah, it's a small one. It's only two days, but, uh, okay, you going check it out, it, I might, I might, I'm looking for an excuse to go to Japan, so, alright.

Yeah, yeah, yeah, yeah, yeah. We'll see how that goes. I'll let you know.

Yeah. Anyway, though, until then, enjoy Srilanka. We hope you've enjoyed our, the platform engineering show.

It is out episode three. If you haven't caught the first two, you can, they're available on your favorite podcast platforms like Apple and Spotify and all of that also on text Drunk TV and, and they uh, text Drunk TV is the website. They're also on the YouTube text trunk tv, YouTube, and I think by the, well hopefully by the next show our Textron TV OTT channel will be up, so you'll be able to catch it on Apple TV and Roku and Amazon Fire as well as mobile apps.

But until then is Alan Shiel Luca Gallente. I hope you've enjoyed the show. Take care everyone.

Thank you Alan. Bye bye-Bye. Thank you everybody.

What's the role of executives in leading large software organization? That's not an easy answer for a couple reasons. First software's different.

And second, it depends on if small teams can work independently or lots of team needs to work together to coordinate work. So why is software different? Well, it's helpful to understand the history of software to really appreciate that and Jim Highsmith done a great job of documenting 60 years of history of software management approaches.

And for those of us who have less than 60 years of history, it's hard to understand everything that was tried before Agile and the problems that they're trying to address. We typically just see how Agile's being implemented now in the industry that we're part of. Jim points out that they started in software by trying to apply traditional management approaches for software.

And while they were able to deliver very large complex things this way, the harder they were to improve and become more predictable, the more frustrated they got. The problem that became obvious as Kent Beck pointed out is that it's because software is a complex adaptive system. It was gonna need a different approach, an approach that could address all the complexities of software, but take advantage of its flexible nature.

They came up with some guiding principles that I think everybody's seeing and the focus when they started rolling this out was how do we work with teams that are developing software to make them more adaptive? And it was all about helping the teams understand how to deal with these complex systems so that they understood how they're evolving. So they understood how to adapt.

And when they proved a lot of success with these small teams, they started scaling into larger organizations. The focus though was how do we scale these small teams into larger organizations? And it wasn't really much on what the role of leaders should be in taking the more adaptive approach.

The best guidance for executives was to empower the teams, remove roadblocks and get outta the way. Well, at HP we really didn't know any better and we started leading the scale, large scale transformation. We took a fundamentally different approach and I essentially after looking back on it, spending a lot of time thinking about it, feel like we really did agile upside down.

The leadership team was the one that was focused on trying to learn and adapt and respond to what was working, what was coming together. And this leadership team over four to 800 developers that were doing a 10 million line of code rewrite of the laser jet firmware included myself as a director, had six or seven section managers that had three, we called 'em distinguished technologists, but they were the, the technical leaders in the organization and the program manager. And that was the team that was really trying to learn how to adapt and respond and take a more responsive approach.

And it was a very large complex system that we were trying to optimize to deliver as much business value as possible. And as a leadership team, we were constantly trying to understand how is this complex system evolving and how do we need to influence the priorities of the, of the organization to optimize the outcomes for the business? And we continued to go down this journey and every month we were, we were setting iterations, we were setting goals and we're trying to learn how to, how to really learn, adapt, and respond to how the thing was evolving.

And at the end of four years, what we realized looking back as we deliver a two to three x improvements in productivity and while we were doing this, we were letting the teams work in whatever method they choose. And when we look back we realize that some teams had implemented agile practices and some didn't and we didn't see dramatic differences in the results based on how they chose to work. At the same time as an organization, we delivered unbelievable Blake through results that we couldn't have ever imagined happen.

This led us to the conclusion that in a large tightly coupled system, the first order effect is the leadership team actively engaging with an adaptive approach. The second order effect is how the teams work. This isn't to say stop doing all the things at the team level that you're doing today.

It's more to say if you wanna deliver the types of breakthrough results that you see on this slide, it's gonna take a deeper engagement and influence by the leadership team. And I thought about this a long time and I'm trying to figure out why does it, why does it really take that more active engagement to really drive the type of results that you need? And I've come to the conclusion it's because the leaders are uniquely positioned to influence the changes that have the biggest impact.

They're closer to the business so they better understand the strategic objectives of applications and the constraints of the business and they're also better positioned to be able to look across the teams. And what we found is when we looked across the teams, that's where the biggest opportunities were for making the breakthrough improvements. And anytime you do something like this, there's gonna be resistance to change, we're gonna have to influence change and the leaders are better positioned for that.

And I think what I'm telling you here is very different than anything you're hearing in the industry where, gee, as a leader you should just empower the teams, get outta the way, remove roadblocks, and and let 'em do their thing and and try to measure them. And since this is so different, I think I'm gonna start with an example from HP of the types of things we did. Not to say that you should do what we did or how you did it, but it's more to give you a feel for the types of things that the leaders are uniquely positioned to influence.

And then once, once we've gone through that and give you a good example of those types of things, well I will review a more active role for leadership, including in using some basic common sense principles that can be leveraged to address your unique, your unique situations. In 2007, I got an opportunity to take over leading HP's enterprise laser jet firmware team. This team had been the bottleneck for the business for over two decades.

We couldn't add a new printer to our plans or a new feature without checking with firmware and usually the answer was no. The firmware supported a lot of new and existing products with different versions of the code base on different branches that created lots of problems. This was frustrating but tolerable until we started getting into copiers.

HP was investing in a new high-end copier and it needed no excuses solution from firmware. This required us to integrate seamlessly in the Microsoft's active directory systems for things like secure scan. The email, the leader before me had tried an initial lease and then determined that this would require not us trying to integrate and and integrate with with Windows XPE and their backend systems, but more developing our code on their XPE platform because at the time that was changing so much we couldn't keep up with all the changes and if we just developed on top of their XP platform, we'd get that seamless integration and security.

They'd also convinced the organization that this would require a complete rewrite of the code base. When I got the job, they weren't looking for somebody to create the plan, they were looking for a leader that could make it happen. The objectives were clear, it was a complete rewrite on xp.

It needed to have all the features of the existing code base or it wouldn't be accepted by the customers and it needed to be done in time for the release of a new copier. This was non-negotiable. This is what we were chartered with this, this is what we needed to go make happen.

But as I brought my staff and that leadership team together, we started looking at this and the traditional approach for this organization for a launch of a new architecture like this would've been going into a months long planning session to show it couldn't be done without more resources and then a few more months going back and forth with the organization to see what we could get in terms of new resources or not and what we could compromise in terms of our commitments. The new leadership team had seen this play out in the past and didn't want to do it again because we knew we wouldn't get additional resources. Instead we focused in on making it happen with the resources we had and when we're trying to figure out how do we execute and make this happen, we started by the, the program manager mentioned, well why don't we just write down a list of the most important things we feel like we need to get done in this month and start working.

And then at the end of each month and every month we would review what got done, what didn't get done and develop plans for the next month. And it wasn't in isolation that the team said that came up with these directives and sent 'em down. It was working with the organizations that was spending time out there understanding what was working, reacting and reviewing and responding to that.

And this was really our fundamental approach to, to really taking a more adaptive approach and spending time understanding how this complex system was evolving. It was very different than anything we'd ever done before. We also realized that while the charter was for XPE for the copier, because we were you know, in the leadership role and we understood the broader piece of the business, we also realized that XPE was expensive and if we were gonna have this be a solution for the broader business, it also needed to scale the Windows CE to be a viable solution for the broader product line.

We also realized that all the branching that we've been doing in the past and supporting all those was really driving a lot of complexity. It was driving our cost structure and we really wanted to move away from that and we wanted to, you know, develop all of our current and release products and all the new features on a common truck. The leadership team also understood that we needed to increase our investment test automation there.

There've been some done up to this point but not a lot. We really felt like this was an opportunity where we could really ramp up and make a difference. These weren't things being asked for by upper management and these are things I can't imagine being driven by the development teams, but we as leaders of the organizations realizes we needed to influence these strategic perspectives if we were gonna be successful.

And that was one of the key roles we played. We also spent a lot of time looking across teams to understand where the biggest opportunities are for inefficiencies. We realized when we were trying to bring together the architecture instead of coming up with a plan and then integrating it later and seeing how the plan came together, what we wanted to do is, is we wanted to have working code of the architecture.

So we started with really thin slices for the architecture, putting it together end to end and keeping that code working on an end-to-end basis. And this really did a lot to align the teams and put it together and it was part of how we were seeing how this complex system was evolving and as we got thin slices, we started creating more thin slices and we moved that forward. We also realized that when the common, when the trunk became unstable, it impacted the productivity of everybody in the organization.

So we started putting in quality gates. We also realized that when we had instability in our tests, we would end up wasting a lot of people's time and energy. 0 that was creating flaky tests and we realized we had to slow down and really make an investment in a different common test framework to get it there.

And these are types of things that I don't think would've ever been driven at the team level. It required a leadership team that was constantly trying to understand how it's complex system was evolving so they could influence priorities across teams that improved the effectiveness of the organization and we're constantly out there learning and adjusting, trying to figure out what would work best. And with any big change like this, there's gonna be resistance.

Most of the developers in the group had been doing things the same way for years and were part of the team that had been at bottleneck for a couple of decades. What had changed was the leader and about half the leadership team, getting them to embrace new ways of working required a lot of influence by this team. The adaptive approach was completely new and just couldn't have happened from the bottom up.

The way we use metrics completely changed. Instead of using it to measure and hold teams accountable, we used 'em to understand how the complex system was evolving so that we could understand what changes would help the organization become more effective. And I like to say I use the metrics to go figure out where I need to have a conversation to learn more about what was going on.

We also realized that several times, like the common test framework, we'd need to slow down for a period of time to get the foundations right so we could speed up later. And if a leadership team, if we were just holding people accountable to deliver to a schedule, I don't think we would've done that. It took more of this adaptive approach of learning or responding and probably the biggest organizational change management challenge was getting people to embrace a common truck.

We've been doing things the same way for so long, they just couldn't wrap their minds around how this would look. If we hadn't been so persistent on this as a leadership team, it never would've happened and it was one of the biggest breakthroughs. There's a lot of other changes, but these are some of the ones that had the biggest impact on the organizations and they're types of changes.

Leaders are uniquely positioned to influence. By the time we completed the rewrite, we were doing things we never thought possible. We were bringing in 75 to a hundred thousand lines of codes of defect fixes and new features daily for all the products.

While keeping 10,000 hours of testing on racks of servers passing at 90 plus percent. If you would've told any of the leaders in the beginning, this was possible. They would've told you you were crazy.

So how do you develop a plan for something you don't think is possible? You don't. Instead it takes a constant focus on influencing priorities and discovering with the team what is possible.

And that's a very different approach than what we typically do in organizations. And it's not what you're hearing from a lot of the software development community where really the role of executives needs to be empower the teams get outta the way and maybe remove some roadblocks. Hopefully this example has convinced you and helped you appreciate the power of having a much more engaged leadership team.

If you have a large organization developing lots of small independent applications or large applications that have been architected to enable teams to work independently, then empowering the teams and removing roadblocks is the right approach for all other big complex systems. You're gonna need an aligned adaptive leadership team to ensure the complex adaptive system is evolving to best meet the needs of the business. A team that's willing to learn and adjust as a system of as evolving.

It starts with a vision. You know, at HPR vision was to no longer be the bottleneck and to free up the capacity for innovation. We had a clear set of objectives and that drove everything we were doing.

And I don't think if it, if it weren't for the focus on that, I don't think we would've ever accomplished the results that we did. It's not like we had an objective to go do DevOps or we had an objective to go do agile or any of those things. We, we really didn't.

We, we were focused on this vision, we were focused on our objectives and that drove what we were doing and we were spending our time understanding how the system was evolving and reacting. The next thing when you pull the leadership team together is to have a common understanding of how that process works today, which is really hard with software development. Unlike manufacturing.

When you go into manufacturing facility, you can see it, you can look at it, you can understand it and you know everybody in the software leadership team's gonna have a unique perspective given their role. And if we're gonna get this aligned leadership team, we need to take the time to make the process visible so we have a common understanding of the issues and we have a common understanding of what's slowing us down next. When we start influencing improvements, we need to understand the hardest thing is overcoming resistance to change.

One of the things I found helpful is moving past industry buzzword to common sense principles. When I use words like Agile DevOps, T-D-D-B-D-D, et cetera, I found people have preconceived notions of what they mean and pre-prepared arguments for why I won't work here. Instead, I've moved to using simple common sense principles that are harder to refute and easier to adapt to your your unique challenges.

The goal here is to provide the leadership with some very common sense principles for talking about all the different types of improvements that might make sense for the organization. It starts with what to develop and the requirements in the planning process. And one of the biggest challenges to start with with software is such a complex system, it can be hard to predict how the customers will use it and what changes will deliver the business value.

Not every idea we have is gonna work. The key to removing waste and inefficiencies from this part of the process is getting feedback from as close to the customer as possible so we can adjust and modify how we're doing thing to help deliver the desired outcome. Second, because of the complexity of software development, leaders frequently don't have a good understanding of the capacity of the organization.

Because of this they end up creating plans that overwhelm the DI development teams and disappoint the business. When the development organizations are over committed, it leads to waste burnout and build up a technical debt. They're just running from one thing to another and they don't ever have a chance to do it right.

And when the organizations don't deliver what the business expects, they start to lose confidence. The key to removing waste from this part of the process requires leaders to better understand the capacity of the organization to ensure they aren't over committed and can meet the business to deliverables while also ensuring there's always a backlog of work for developers so they have something to work on if they finish the commitments early and that's a right priority that you wanna be working on. The other challenge that a lot of organizations have with the requirements and planning process is they end up with so many requirements that they're working on that they tend to start taking on a life of their own.

It's so much easier to create ideas than it is to do 'em that a lot of times you just collect this huge backlog and then you're managing it, you're prioritizing it, your whole meetings. And the key to really improving the efficiencies here is to limit the work that you put in on those requirements to just in time when it's needed to either support a business decision or enable to support development. And if you're doing that, it gives you more flexibility to adjust and to respond to what's out there in the marketplace.

Once we understand what to develop, a lot of it comes into how, and then when I think about the how I think about the architecture and as a HP examples showed architecting for a common trunk, the architecture approach can have a dramatic impact on the efficiency of the development process and the value of the product. The current or planned architecture can be be a constraint or enable enabler left to the architecture. It will probably work but might not be optimized to deliver as much business value as possible.

Gain you the common understanding it not just an architectural map but visibility into the implications of that architecture on the product and the development process. Does it require lots of different teams working together closely? Are there clean interfaces where it's easy to test separate components?

Is it tightly? Is it tightly coupled to the hardware which makes it difficult to leverage capacity in the cloud? Is the current architecture inhibiting or enabling what the business needs?

Once you have a good common understanding of the constraints of the current architecture, you need to decide if the impact on the business warrants the risk associated with the architectural changes. At hp, I didn't have a choice. The job was to relight 10,000 lines of code from the ground up.

It was the hardest thing they ever done. It put the business at risk because we couldn't release another product until it was complete and it set the Del delivery team up for a death march. Sometimes complete rewrites are required and maybe it was this time, if possible I would recommend avoiding it.

If you do feel like your current architecture is a constraint, looked at a lot of the stuff Martin Fowler's done in terms of taking an evolu evolutionary approach to modifying the architecture over time without doing the complete rewrite, I think it'll be easier on your teams and less risk for business. The next part is how do we really improve the creative process of creating software? One of the basic principles is building in quality.

Shifting to building in quality makes a big difference. Manufacturing learned a long time ago that the only way to be successful is to focus on quality. They did this by controlling the process because the process was creating the same product repeatedly.

Software is different in that it involves a person working with the business to create new and different solutions each time. Instead of controlling the process, we need to work on giving that person the best possible feedback on the intended and unintended consequences of those changes with the rest of the system. The quicker we can provide this feedback, the more help it is to the developers in terms of limiting wasted times associated with going down their own path.

The magnitude of this issue can be made visible by macing. The feedback delay and implementing improvements can be occurred by either moving the feedback closer to the developer or moving the code through the deployment pipeline quicker. There's also coming out a lot of opportunities with AI to really start making a difference.

You know, at HP we realized that eventually our developers became the constraint and we were doing everything to make them more productive. We were buying headsets, noise cancellation headsets, we're buying bigger screens to help them become more productive. And now there're just a bunch of things coming outta AI in terms of either code suggestions or ideas or maybe automatically generating um, unit tests or trying to help you debug and triage.

I would, if I were actively involved with a team right now, I'd also be looking at leveraging that to help me make them more productive. And it's evolving quickly and what I'm hearing from developers and organizations is just, it's starting to make a real difference in terms of the productivity of developers. Software also has a lot of repetitive tasks.

Anything from creating an environment to building the software to deploying, to testing. And just like we do in manufacturing, we can automate these things to make 'em more consistent. We can automate these things to make 'em more affordable so we can run them more frequently, which helps to reduce the batch size and make it easier to debug a triage, which takes a lot of effort in software.

And so these types of repetitive tasks are a lot of what you hear talked about when you hear people talking about DevOps is just how do we make these more repeatable? How do we work in smaller batch sizes and how do we go through that? Software can also leverage some ideas that started in manufacturing and this is, you know, how do we remove waste and become more efficient, um, over time?

And gold Rat has pointed out that you're not gonna get more through the organization unless you get more through the bottleneck of of the process. And so he taught us the key to optimizing flow to the customer. We need to understand the source of the bottleneck.

We need to make sure it's never starved for work. We need to do everything we could optimize its flow and limit the work and process for software. The bottleneck can be in requirements development or the release process.

While it's possible for it to be in the requirements process, it doesn't happen very often because it's easier to come up with ideas than to implement it. It's usually either in development or release. And the first step in improving flow to gain a common understanding of the bottleneck.

If the bottleneck is in the release process, we should really be looking to automate the repetitive tasks so we can work in smaller batch sizes or release more often if it's with the developers, which is kind of where we want to, 'cause it's gotta be somewhere we can really work to sort of how do we make them more productive over time once we get through that. So there, these are some very basic common sense principles that I think people can use to talk about instead of just copying, well this complex framework because it worked over here, it worked and did something else. The key to getting started is to engage the, engage the leadership to influence how the complex system is evolving to deliver as much business value as possible.

They need to be clear about what they need to accomplish and have a common understanding of the current process. They need to agree, agree on the improvements they feel will best address their unique challenges. Hopefully the common sense principles will make that easier.

Finally, to help overcome their resistance to change. I recommend working in small reversible steps, one iteration at a time. This enables the team to learn and adjust as they start making changes.

With this approach that the team can stay aligned as they work one iteration at a time. It's less important where they start. So they have the ability to adjust, to take advantage of the adaptable nature of software.

And if we let them pick where they wanna start, they're much less likely to be resistant to change. Thank you for your time. Hopefully I've convinced you that for large organizations where teams work together, there's a much more engaged and adaptive role for leaders.

This top link is an 18 page paper that I wrote for busy Executives. That's the basis of this presentation. My goal was to rise to gold Rest challenge of if you don't understand the problem well enough, you can't explain it.

Simply my hope was to turn this into a book, but when my focus got on clarity, got it down to 18 pages, it fit the time constraints of busy executives, but missed the marketing target as a book. I chose to stick with meeting the needs of the reader and I would've written even less, but I ran out of time. There are other pages, papers in the resource tab on my website that you also might find helpful as you're going off to different chances.

And if there's anything else I can do to help, send me an email and I will try to point you in the right direction. My email address is there and I tend to respond to things that I get. So thanks again for your time.

Hopefully I've convinced you to take a different approach to deliver what your business really needs.