Techstrong TV – January 6, 2024

Happy 2025. We're kicking it off here on Textron Gang. Hello everyone.

It's Alan Shimel for Techstrong Group and welcome to 2025. It's our very first, uh, tech strong gang episode of the New Year. We're excited to bring it to you.

We have some of our core gang people with us, and we're gonna be talking about what we think 2025 has in store for yet. Um, got a lot to go over. Let me introduce you to our gang members right off the bat.

First of all, joining us from home in Colorado. He's a future vp, analyst, tech drunk, CTO, my friend Mitchell Ashley. Hey Mitchell.

Happy New Year. Good to be here. Welcome.

Hello from snowy Colorado. We had some snow this weekend, so, you know, it's, we're, we're living The good life. I don't know if Snow's living the good life, but hey, good for you.

It is here and you're a skiing destination. Yeah, I guess it is. It's good for skiing.

Well, um, it probably is snowing by our next guest house too, 'cause she's also high up in the mountains. She's the deploy hub, CEO open source, uh, open source aficionado extraordinaire, our friend Tracy Reagan. Hey Tracy.

How are you? Hey, I'm doing great and no, we're having beautiful we weather in Santa Fe. We haven't got quite the snow yet, so, you know, I feel I've been working, but I, and I feel guilty for not going out and enjoying the, the weather.

It's been so nice. So I'm hoping it continues. I hope so too, Bro.

I'm okay with that snow. Me too. Uh, I don't know if it's snowed up in New York yet though, but our chief officer ARDS up in Westchester County.

What do you, what's the weather report there? We, we had a fierce two inches of snow that stuck around for 48 hours. So, you know, it was kind of, you know, new experience in New York.

Apparently it hasn't snow here in any Significant, no Volume in A while. The thing about snow in New York is after 24 hours it gets kind of dirty. Yeah.

Black snow. Yeah. I, I don't like that.

Well, let me, if anyone's interested, we have not had any snow here down in south Florida. Um, it, it has been around 80 degrees and actually around New Year's. The weather turned nice for the first time and I don't know how long and I was able to go on my boat and, and enjoy some of the beach in South Florida.

What, what we're known for here around Christmas, new Year's time. So it was a, uh, it was a great, it was a great holiday. We were off for about a week.

I hope you all enjoyed your time off as well. I know, Mitchell, you did it. You were under the weather.

Yep, a little bit under the weather. I'm doing better now though. Much better.

Not dead yet. Not dead Yet. Yeah.

Did you have a cold? I caught one myself. It's like a five day job.

Oh, I got that strep that was going around, so not fun. Oh, you Were sick too, Mike. Yeah, I caught a cold.

I think it was my own fault. I went to the pinstripe bowl and it was raining and so There you go. You know, a lot of people I know in, in cold weather had the flu strep colds.

Yeah. Yeah, it's tough, tough, tough, tough. I mean, I'm glad you're all feeling better though.

So, Hey, you know, I went, the pinstripe ball was at Yankee Stadium and a team from Boston lost, so it wasn't so bad. Well, as long as we're talking sports, you know, I'm looking forward the orange balls coming down here next Thursday, uh, Thursday night, and, uh, it's gonna be Penn State. We are Penn State versus the fighting Irish of Notre Dame.

Yeah. Who I spoke could not be Georgia, but they did handedly couple Classic powerhouses Right in. Yeah.

Looking forward to it. Looking forward to it. Speaking of Thursday the ninth, we also, of course, you know, we lost President Carter over the break and, uh, he'd lived to be a hundredth though at, you know, and had quite a productive life after leaving the White House.

There is life after the White House and, um, Thursday the ninth is going to be his like, I guess national day of morning funeral session, whatever. And we did have predict our annual predict, uh, events scheduled for Thursday the ninth. But in, in respect to President Carter and the National Day of morning here in the us we are moving predict to the following Tuesday, which is January 14th.

We'll be sending out emails to everyone who's registered and updating for promos and social media and so forth. But we are going to, uh, tip our hats to Jimmy Carter. You know, it's funny, not so much for what he did as president, though.

He, you know, there was some important things he did in president, including the Camp David Accords, but almost more for just the decent human being He is. He was. And, uh, well, we're not gonna get into politics on the first day of 2025, but he's a, he was a decent human being and outta respect, we're gonna move, predict, um, Mike 2025.

What, what do you, well, speaking of predicts, what do you think? Well, You, you, you said that we weren't gonna get into politics and the first thing in 2025, and since you and I frequently disagree, I must say you're wrong because that's exactly where we're Brand new. The mic.

Well, I guess Like new year, same as the old year. Right. But, but I'm gonna start from the far right and I don't know if you've noticed, but, uh, Steve Bannon is outta jail and up to his usual tricks again.

And he seems to have targeted Elon Musk and he's gonna bring a boatload of it issues into the political spectrum. He is already done it with, uh, there's been a fight over these, uh, visas that we give tech workers. There's already been a topic of discussion.

I think that's gonna become a much more heated conversation. He's also starting to tag Elon with, uh, being too close to China, and that's starting to catch some traction out there. So we're gonna see all these issues around semiconductors and everything else become a bigger issue.

And then I'll bet two other things. I bet that he will discover that, uh, AI and EVs are driving up the cost of electricity for the average consumer, and he is gonna start banging on that drum. And then finally he is gonna wait for a big merger to happen and then go after Elon and say, Hey, you're part of this big tech conspiracy and you're basically gonna try to hamstring us all again with the whole conversation about, you know, who's being censored for what.

But it seems to me, here's the prediction is that it is gonna be front and center in this political fight that's gonna happen. And it's not gonna happen on the left. It's gonna happen on the right.

I think that's a really good prediction. That's an interesting prediction, no doubt. Mm-hmm.

I think also, you know, we're already seeing, you know, with the Federal Appeals Court striking down the, uh, net neutrality things that the, uh, FCC was trying to do, and you weren't gonna see a lot of things changing on the tech front just because of administration changes and philosophies and supreme courts and courts and all that kind of stuff. I think it's gonna be kind of a, I dunno if the rough and tumble is the right word, but it's gonna be a, an interesting rollercoaster ride here this next year or plus, I just don't think anything will get done. So I don't know what, it might be a pretty flat ride.

I think. I think we'll have a lot of, we'll have a lot of, uh, um, I don't know, hot air, but I don't know if anything will change. And sometimes hot air is great for disruption, right?

And maybe we need a little disruption. Uh, maybe that's why the country chose the person that they chose. But again, I think it'll be a lot of hot air because incompetence doesn't always get things done.

And I think we'll see a lot of that, to quite honest. That's my prediction. It's true that we may be looking for some more, uh, adult supervision to Mitch's point.

If we don't have any of these agencies who are in charge of anything, then you know, who is gonna make the ultimate call? Because they might just always land on the president's desk, I guess. But, uh, you know, they'll have to have a law.

And then to Tracy's point, you have to get somebody in Congress to agree to something. So, I don't know Alan dysfunction more of It. What do you think?

You know, I'm trying not, I'm trying real hard not to be the ma ma mahi or that's gonna take, Oh, come on, come on, Allen. Unleash the kraken, unleash the crack, Unleash it. How have we had enough of Steve Godda baton?

It Apparently Not. This, this, this, this is an anarchist who would be only happy bringing down our way of life. And when are people gonna wake up to that crap?

I mean, I'm no Elon Musk fan. God knows it. If you've listened to me, you know, that's to be true.

But first of all, you can't blame Elon for everything that happens in the world attack, number one. Number two, you know, Steve Bannon praise plays the part of the tri like king, but built his empire by using technology. So he's a fraud.

He's a fraud. And I, I think his 15 minutes are up. And, you know, I think Donald Trump and the administration would do well to just freeze him out as they did the last time.

Right. Freeze him out. He, nothing good comes outta this man for our country or our citizens.

Uh, does big tech need some guardrails? Yeah, probably. Is this the administration with, with the oligarchs, you know, financing it to do it?

Probably not. It's going to be a laissez fair, wild, wild west. We're gonna have ups downs.

We're gonna have the usual chaos that, that Donald Trump likes to wallow in. You know, that. And that, that's gonna be the, the fact, honestly, keep your head low, get through these four years and hopefully people of the United States will, the common sense somehow will return here.

It'll be interesting to see what kind of an audience, you know, he continues to draw. Whether that'll become narrower people that, you know, strongly view what he views or, you know, is it kind of the larger MAGA audience, if you will. Uh, I, um, I remember I love this quote by, um, you remember the comedian Bobcat Goldway Sure.

In popular long guy. He had this quote, he had this thing in his, one of his sets a long time ago. He said, you know, when I was in high school, Haven't done anything recently, Mitch.

No, no, I don't think he has either. He said, you know, I found out in high school that I was fifth from the bottom of my class. So I went and found the other four guys and I became their leader.

So maybe that's what we have, we have here with Bannon. We'll see. Yep.

I, uh, I agree. But, you know, and, and quite frankly, I, I don't think the US will be the center of government action in regard to tech. I think it'll stay at the eu.

Oh, certainly in terms of regulation. If anything, you'll get less in the us right? Yeah, I, Yeah, we will not, I don't think we'll drive any of the, uh, new policies that's gonna come out of the eu.

And if we wanna do business there, we're gonna have to follow it. So, But, but what's interesting also though, not from even a tech point of view, but from a political point of view, is, is this his classic, you know, political theory, right? So now you have the right ascendant with all three branches of government and the judiciary for the most part, right?

With the pact Supreme Court. And here they are self-destructing, right? You'll have the tech heads at war with the diehard trilight mags.

And so, you know, will they be able to govern what, given that divide? And probably, you know, it's gonna create some chaos. It's gonna create some paralysis, and so be it.

So be it. Exactly. So what are you, something you said, Alan, you know, you used the, the term laissez-faire.

I predict, well, let's, let me back up. Okay. We have to talk about American Airlines.

You have to talk about American Airlines sending out a update on Christmas Eve. We, I had a friend coming in from Chicago, and it took it, his flight was delayed for 24 hours, and he spent the night Christmas Eve and Christmas morning at the Dallas-Fort Worth airport with 800 other people who were stranded because of that release. Now, I wanna point out that we have this, John Schwartz talked about this once, and I think about it all the time.

Authoritative bias. I feel like we have in, in, in 2025. We are gonna be looking at this authoritative bias across many industries.

Politics. Somehow Elon Musk is the person that we should turn to, right? Um, when it comes to fixing our government, he has no background in it.

But let's go ahead and put him there. I don't know why. And we have, we haven't tricked that kind of philosophy in that Annette Twitter.

I know. It's like, can you think that would be the exact opposite? But why do we still have after Delta, you know, had their experience with CrowdStrike?

Why do we still have third parties updating software? And I believe, and I predict this, that we're gonna see more of that kind of problem in 2025 because we have forgotten how to do DevOps. We have thrown the DevOps process away because we were relying on authoritative bias.

And it's becoming part of our culture in a very odd way. I mean, there was no reason for anybody to ever do a release, uh, Christmas morning, Christmas Eve morning, that was just stupid. Or whenever they did it, maybe on the night of the 23rd, whatever it did, it stranded a lot of people.

But why would they have done that? Why didn't they, why didn't the testing process go through what happened to DevOps and where has it gone? So I, I really think that we're gonna see a lot of these, these massive dis disruptions because I believe that we have that authoritative bias now in our culture, and it has taken over some of our processes.

And in DevOps, that is so true. 'cause now we've seen two airlines have massive shutdowns because of an update done by a third party, which I find to be absolutely crazy, crazy crazy. How on earth are we doing that At this point in time?

We've been doing, talking about DevOps and tightening up releases and having a process for how long? 30 years. As long as I've been in business.

So where, you know, that just baffles me. And I'm afraid that 2025 we're gonna see more of it and we'll probably see a lot more vulnerabilities come through and hit the hit, hit the market. You know, having been in security as long as I have been, I have a little different view, Tracy.

I don't blame the third parties, right? I, Mitchell will tell you, we, we had the brilliant idea when we were selling ideas is that instead of, instead of just selling it as software, we were gonna sell, well first, excuse me, we were selling appliances. Now, there's nothing fancy about the appliances.

They were X 86. But what was great about it is we knew what hard drive, what, what network card, what, you know, what software, what, what, what was the foot physical footprint of our appliance, even if it was just a Dell box under the hood. And then we weren't selling enough appliances and the, and there wasn't a lot of margin selling hardware.

And we said, you know what, back with it, we'll just send, it runs on net 86 Linux. We'll just sell software. And we started selling software.

What a frigging mistake. What a mistake. Because all of a sudden we had to make sure our software ran on every network card, every data hard drive, every configuration, every motherboard, every, you know, back in the bus, in the IRQ conflict era and all of that.

And it drove our support and, and development and Mitch Ranch support and development. He could tell you this firsthand. We couldn't support all the infinite variations, uh, you know, let alone the Dell Compact.

Hp IBMs what about all the white box stuff, right? Coming outta, Well, in that case, we owned the whole stack operating system up. So it was a software appliance if you'll Yeah.

That's why that caused so many issues. So It's the same thing for third party software vendors who are, you know, putting their apps out on platforms. It's very hard to anticipate every configuration, every nuance, every variable that can be on any particular platform.

But to me it's more, Mitch, you remember our friend Peter Fisher at Citigroup back then? Citigroup, Yeah. CIO at Citigroup.

Yeah. One of the three global CIOs at Citigroup. They used to take 90 days to do a patch Tuesday.

So Patch Tuesday came out every Tuesday, right? Or excuse me, once a month or whatever it was the third Tuesday of the month or whatever it was. They were always three months behind because they wouldn't roll out that patch until it had been thoroughly tested on their particular systems.

They didn't care. There is a middle ground though. Equifax is a perfect example.

They didn't update that, uh, vulnerability drugs for way too long. 'cause they didn't wanna push it out. But we have gone beyond that.

DevOps has actually allowed us to do much more in a much shorter timeframe. And there is no reason why a, you know, somebody like American Airlines doesn't have a model office system where they deploy that those patches before go out to production. Well, but to your point, it's really to your point, it, it, it's, it's not an all or nothing, right?

We don't have to live in an all or nothing world anymore. And that was one of the lessons with CrowdStrike, is don't push the update whether you do it on Christmas Eve or morning or you know, the tu third Tuesday of, of January. Don't push it all out at once, you know, incrementally and don't push it in your main hub.

Right? Right. In in Dallas, that, that was sort of the idiocy of that, right?

Put it out there on the edge somewhere that if, you know, Fargo goes down, okay, we're sorry Fargo, but it's not the main hub or whatever it might be, sorry Fargo, but, you know, be intelligent about how you run it. Be incremental. You don't have to push it all out everywhere.

And that's part of, if you've, if you're taking advantage of the cloud of the network, that's some of the capabilities that you have now. You have to be able to architect design things, rework things so that you can do things incrementally. Not everything is easy that way, but that's, that's the world we live in.

And you don't build res resilient systems without doing that kind of thing. But ultimate, I don't think It's authoritative bias though. I just think it's, uh, inertia.

I think it's probably the, you know, the last Monday of the month, there's a regular update cycle and nobody thought through the fact that that was probably gonna impact Christmas on that Wednesday or the Tuesday when they normally do it. And so somebody just hit a button because they were supposed to, 'cause it's that day of the week. And I don't think they had a plan.

I think they were just kinda operating on autopilot and didn't realize what was gonna happen. And I think that's all too common. I think there's just a lot of these Processes That are, uh, mindless because nobody actually correlates them to, you know, airline traffic.

So. Absolutely. And I, I agree a Alan, it's not that it wasn't the third party's fault.

Mm-hmm. I've, it just like I said about Delta and CrowdStrike, they are responsible for their own systems and making decisions on who can push things out and the process in which it is pushed out. But I do believe that we have forgotten some really basic DevOps principles and makes me really sad.

Oh no, It Really Does thing here. There's a cultural thing. It's Cultural.

Yes. Lemme go back to, I was still secure days I was talking about earlier with Mitch and I, right? So we were one of the first to market in what we called, or what the industry called IPS Intrusion Prevention systems.

Up to that point, state of the art was IDS intrusion detection systems. Now, back then, I was a young whipper snapper. And, uh, I thought, ooh, who would be satisfied just detecting an intrusion or a mal, you know, an attack, potential attack.

Of course you'd want to prevent it. So if I had the ability to prevent that attack instead of just detecting it, no brainer. No brainer.

Well, no bueno. It didn't work like that. People were like, oh no, I can't just block traffic worm.

If that's important to my CEO, I'd rather suffer the attack than have the CEO get mad at me 'cause I blocked his porn, or something like that. Right? And Mitch, you know this, it took Mitch, I were both gone from still secure before IPS became the re gore, you know, the, the Andrew versus IDS.

Same thing in vulnerability management. Is it enough to find vulnerabilities? Heck, why can't we just patch it while we find it?

No one perfect. Yes, hundred percent My stuff. Just tell me, gimme the telephone book of vulnerabilities.

I'll patch 'em on my own. Right? No, I put the patch should just be done automatically.

At least a poll request. This says a patches there. Tell you what, the problem that caused this down foil here is I reach into my pocket.

This thing, this thing, this has ruined software updates. This has ruined security for updating because we've gotten so used to this thing updating on its own in the background that we think that's how it goes. We no longer, none of you can tell me which apps were updated on your phone when, 'cause it just happens.

We have said, oh no, it's just an update goes on all the time. We don't worry about that crap no more. We don't do our QA testing, we don't do our DevOps.

We don't do a digital twin, we don't do a test environment. My phone updates twenty four seven and it's been the run. And it, it's responsible for CrowdStrike, it's responsible for America and airlines.

It's responsible for all of it. Same can be said for all the SaaS applications, which some of those are, Well, you're starting off 2025. A little growly there, Alan.

So, no, I'm sorry. I'm sorry. So lemme take, somebody has said AI yet, so I'll bring it up to your point about author of bias.

A lot of, a lot of what is coming out is agents that will do work for you, like updating software, applying patches, maybe doing upgrades. That's, that's, that's the path that least we're headed on, headed to, you know, are we running into a, a brick wall there of the authoritative bias as well? AI do it, it figured out it was supposed to do it, and it's supposed to know how to do it.

So we let it, you know, we, I blanked up. I trusted it. You know, just to put a quote, a famous movie, grander, what?

Why am I gonna Tell Fred, Oh, my car? So not his car. But it seems, well, if we can, that's the next thing we're gonna run into, right?

If we continue down this good, Mike, Go by. So let, let's, let me put a theory out there that you think we'll see in the coming year, an effort to take back more control from these SaaS apps. Because people are also gonna wanna take more control of their data destiny and the age of ai.

They're gonna want to own that data, be able to apply it and train in and use it where they want. And too much of what they're realizing today may be that, you know, in addition to being dependent on third parties too much, that they don't own their data and they're gonna kind of say, Hey, we need to take back control of it. In general.

I think it's all relative to what it is, right? If it's the CrowdStrike agent that runs at the OS level and can block anything if it fails or cause it to crash, yeah, I might want to be more diligent about it. If it's the fitness app that my people are using on their phones, going over my wifi network, I don't care about that stuff.

Or that's sort of an extreme case, but maybe there's a lesser, you know, if, if, if my whatever system goes down internally is not gonna stop the manufacturing lines, it's important. I, I think the thing to take back it, it isn't necessarily just a pendulum swing, Mike. I think what we should take back is how do we make our systems resilient, right?

Just taking it back just means we now own it when it fs up, right? We're the ones gonna be on the hot seat, not the vendor. Um, and we already are with the vendor, but in this case, we're gonna be the cause of it If we didn't properly, you know, do whatever the steps are, do be diligent about it there.

My question is, well, what we want to have is, hey, things happen, right? Stuff happens whether we do it or the vendors happen do it, or the, the SaaS providers, whatever it is. How do we recover?

How do we quickly recover, come back up, go back to the old version, et cetera. We're just on kinda this automatic upgrade path. Then I think in many cases, we don't know what we would do to get back to the last version of a p And that was the case with American Airlines.

It took 'em an hour. Mm-hmm. It took them an hour to do a rollback.

You know, we, I think that, you know, maybe in 2025 we should revisit chaos engineering and understand that the ability to quickly fix a problem is so much more important than the root cause analysis because we don't know what it, you know, it could be, you know, it could be somebody sneeze and hit a key wrong, right? That could be the chaos that that caused the outage. Probably not, but it could be, right?

It could be just a a a f figure typo and a configuration that takes forever to find. But chaos engineering taught us that being able to quickly respond to outages and prepare your team to do so is the way forward. And I believe that, you know, I don't think that most companies have really, I doubt if they have game days in trying to be able to teach their staff to, to be able to, to quickly get back online.

Certainly American Airlines has make, because an hour is a long time, an hour stoppage means that anybody who has a connection is gonna get screwed. It's about the system. And that's what happens.

Rebound not just, you know, not just points. Right? How many assists, how many rebounds do we get?

Yes. Yes. Well, maybe, so that's my prediction for 2025.

Maybe that connection shouldn't involve me trying to get from one end of, uh, Charlotte, North Carolina airport to the other in 10 minutes though. Right? That's true.

I read a, I read a blog by a, a flight attendant, um, and basically she said, if it's less than several seven hours drive, Well, there, there's something to that with all the prep time and everything. I think connection times I've gotten shorter too. What we think are acceptable.

Well, no, what, so here's a little pet peeve of mine that I'd like to see change in 2025. If you speak to the airlines, they're actually gonna tell you they're on time more than they ever were. Because what they've done is they've built, built-in buffers into their schedules.

So like for instance, you know, the, here in Florida we have sort of an underground railroad up to New York, Mike, Mike notes that from an airline point of view, every airline here runs like buses from Miami, Lauderdale, PBI into Kennedy, LaGuardia or Newark. And it's a two and a half hour, two hour, 20 minute flight. But now the airlines are scheduling, they used to schedule 'em for three hours.

Now they're three and a half hour in flight because they're building in time off the gates and stuff like that. But what they're really doing is building in extra time so that they could show their early more than they're late. And so, even though you got a 55 minute layover right, connection point, you probably have closer to an an hour and a half because there's that extra buffer time built in to these flights, assuming everything goes well.

And, you know, you could fool some of the people some of the time, but quite frankly, Delta and America reap what they sell because they're, they're not, they don't play nice in, in all honesty. Right? And it's not just the two of them.

JetBlue does it. Southwest does it. They all do do it.

They, they've buffed up the, the flight times to make it seem like, you know, they're, they're on time or even early, you know, and, and that pilot when he lands, and he thanks you for flying their, for the airline today. And we remember this the next time you're late, that we got you in early today. Oh, you got me in on time.

It's just your schedule Yeah. Look like the hero. So yeah.

Right. And we worry about bias in our large language models, right? We've had bias in data for a very long time.

Yeah. I, you know, again, I'll go all Steve Bannon on him. This is a, This is, This is, this is like the old sales rep who, uh, you know, when his spouse was complaining about the fact that he was traveling too much though.

And then he started telling his spouse that, you know, the show that he was going to was four days long, when it was actually only three days long. And he comes home third, Hey honey, I missed you, right? Yep.

So, Yep. The surgery was a success, but the patient died. Yes.

If I can turn the, turn the lens and, and focus in area one, one of the areas that I'm really most interested in because of the analyst coverage that we do, is around code generation with ai. And I think 2025 is the year of the code generation specific LLMs including code quality, secure code, things like that. We've, we already have some of those available today.

I mean, Jett ptt, excuse me, Jett P four, um, you know, things like code at five and five plus Code Lama, et cetera. Open AI has their own code X for code generation, but also the other providers like the Microsofts, the GitHubs, the AWSs of the world, uh, having not just codes generation specialized LLM capabilities, but specialized to their environments. I mean, who knows better than than AWS what their environment is like and how best to build applications within it.

So I think we're gonna see a lot of bifurcation, not just, I use Microsoft or I use uh, GitHub's copilot and that's my, that's my pilot. No, that's your window into whatever LLMs or services that you're gonna use. So I think that's gonna be the big focus around at least the code generation part of ai.

I think they, the chip manufacturers are gonna get more involved in software too. I think like Nave is gonna get much more involved in AI building AI systems. It just chips.

Here's My prediction from left field since I started with right field earlier. But on the left field, I think you're gonna see org charts in IT organizations and enterprises be ripped up this year. And I think a lot of that's gonna come back to this platform engineering conversation we started in 2024, where a lot of those people are gonna decide that, hey, you know, all these little specialist teams that we have created over the years are counterproductive and they're gonna start pulling all that into more centralized functions and require IT people who can do multiple things rather than, you know, standing around saying, I'm the infrastructure specialist for this, or I'm the cloud architect for that.

I think we're gonna see a much more, uh, homogenous team of IT folks who can manage multiple things, working hopefully more hand and glove to do things at scale. Oh, contr trip. I hope so.

Oh, contra. Alright. Point Point.

Johnny Carson talking to Ed McMahon, the amazing Carac Oakman shrimp, ms. Sure. So I think you got that platform engineering thing all wrong.

Do you, I think platform engineering is about building silos, not knocking them down. I think platform engineering says I want my little guys who do that little do that thing and I wanna keep 'em as a separate team doing their due dates. I want them to communicate.

Right? I think platform engineering at its heart is about cross silo communication, not busting down silos. And so those teams are not going to go away.

They hopefully will just communicate with, with the collective and be assimilated. I believe they'll be assimilated, that's for sure. Yes.

Well, the thing that would drive, drive collapsing it to your point Mike, is cost, right? If you can demonstrate true cost savings that don't have a major impact on delivery speed or things like that, maybe it's improving it, that would certainly push you to consolidate. I think The issue too is like even today, if you look at the cost of it, the single biggest factor is still labor.

And I think people are gonna start to look at that harder and say, how do we reduce that particular cost? Yeah, Well maybe we'll have code bakeoffs and we'll have, uh, platform Bakeoffs, we'll take my platform design or platform design from one LLM and com use another one to compare it it against two different L lms. So things like that.

I think we think of the ability we have to compare allies information. I finished some papers in 2024 around using AI to really di dive into the depths of what an architecture and what functionality and applications performs before you modernize it. That's half the battle is just knowing what things do and who the people who wrote it on around anymore.

And if you're gonna, you know, move it to the cloud or start updating parts of it, or maybe rebuild parts of it, you know, what is it you gonna, what are you gonna leave on the cutting room floor? You don't realize. And AI is very good for that.

There's a lot of really good analysis tools for that now. So I I I gotta jump in on this whole LLM issue though. So here's my prediction for 2025.

Something's gotta give with LLMs and there's two, there's two issues of it and two points to it in my mind. Number one is, are we serious about organizations near and far being able to create their own LLMs and maintain them? I don't know.

Not unless we somehow make it a hell of a lot easier to integrate and stuff like that. Mm-hmm. And so the logical flow of that is okay if they can't create and maintain their own LLMs, except for the big guys, they're gonna have to use prepackaged lls who owns the market for prepackaged LLMs?

Well, at the very general level, I think we've already see this market being defined. You've got open AI chat, GPT, you've got Claude Philanthropic, you've got Gemini probably from Google, you know, apple surprisingly is borrowing or partnering with all of the above. But let's face it, eventually they're gonna have their own As, and you know, Microsoft's open AI thing.

I will, who knows where that goes? Musk invested how many billion in Right? Much as X AI or whatever X but Mitch, here's a, you know, something Brad Feld always told us Top three, If you're not in the top three, get the hell out.

So my, my projection is by the end of 2025, you're gonna have three major, let's call 'em general purpose LLMs, mega hyperscale LLMs, and they will be owned by hyperscale tech companies. Then I think you're gonna see a market underneath that for the specialists, for the specialty LLMs, for law, for medicine, for finance, for, you know, I'm, I'm, I'm hitting the usual suspects for tech, right? You'll, there will be a market for specialized LLMs that are kind of off the shelf 80, 85% and can be modified 10, 15% for your individual company.

And that will be, instead of developing your own LLM, that'll be the LLM you use when not using one of the hyperscaler ones. So I think that's how the LLM market shakes out for 2025. And you heard it here first, I think we're, I think you're, you're right.

And we're living the first half of your prediction already. We're already see who the major players are, and then there's some things coming up along the side like, um, deep seek, which is funded by the Chinese, you know, we'll see if that becomes a, you know, a, a hands off kind of thing. But there are things that are gonna come up like that, that will be new advancements there.

There's a lot of innovation around how to create LLMs much faster, lower cost, you know, more efficiently. So there's a lot of, we're in that, how do we make it better, faster, kind of phase two to your point about having specialized I agree with that. I think the other thing is you'll see more things like their neural magic acquisition by Red Hat, which is about deployment of LLMs deployment of AI software or, and access to multiple LLMs.

If you look like even at, with at Elastic, you know, they have an environment where you point where you want it, you know, in your, uh, vector, vector database if you will, front end to your, your rag, where, what model you want to use to be able to do that part of it. So a lot of this is gonna be choice, right? And it's gonna be built into the software that we use.

You only have to download the LLM necessarily to set it up and use it. You'll use it as part of the service that's online. I think it's gonna be more about, well, I guess what people are calling, uh, small language models.

And I think some of those will be based on foundational LLMs that the big guys are providing. But over time, those LLMs or the small LLMs will become foundations for other LLMs and they'll start to multiply. And each of those things will become easier for an organization to create.

I don't have to create a massive LLM for every task. I can use a smaller language model and then I can, uh, theoretically at least create my own AI agent off of that SLM and I might go from there. So I think that there'll be a move towards, uh, small, beautiful in the space of ai.

You can see the big guys, I think the ai AI agents, Yeah, I think AI agents are gonna be a problem as we move forward. I agree with, I always talk about it, but we're all, we're gonna, there's gonna be so many of them and to not, if you're not able to kind of version 'em and, and track 'em, we're gonna get serious drift in that, which is gonna be a issue and probably bring down airlines. Come on, you're gonna need agent hygiene, right?

You'll need Ag Agent hygiene, otherwise you're gonna have rogue agents that are floating out there. Like you have subscriptions for SaaS products now, right? And I mean, and this is not new in tech.

I mean, think about cloud. How many, how many unused sessions, instances are there on an AWS that were open and never closed, right? And they're getting charged every month for it, but it's pennies and so they don't recognize it.

Software on your computer, how much stuff Do we Have installed on our laptops? It isn't. Use And Google my refrigerator.

I spent earlier this morning clearing out all the, if it, if we had it during Christmas and it's January 6th, it's time. I'm not gonna eat it. Put that out.

I think we'll see a lot of cleanup on aisle six agents, you know, go out there Like clean. Well, that I think is what you're gonna have. You're gonna have Agent Smith, right?

Who cleans up Rogue Agents? That one's gonna be called oh oh seven, right? Yeah, I know it'll be a hero, but, you know, red pill, blue pill, Steve Bannon don't care.

Or the above. Anyway, Hey guys, we're, we're 45 minutes in. Um, I'll, does anyone have any other prediction they wanna throw on the pile today?

Or when we come Back to talk about regulation? This is the year of seeing some enforcement in there is like software security starting of it. So we should spend some time talking about that another time.

I think regulation. Well, about, about, about Steve Manon. I'll share some wisdom from a former publisher of mine who said, you know, the one thing in the world you should always remember is it's a lot easier to throw grenades than it is to catch a Absolutely, at least as it applies to the us.

This is not a year for regulation. No, not a year for regular, sorry, it's la As I said before, it's laissez-faire, whatever goes batten down the hatches. Keep your head slow, guys.

I'm sorry. Um, if we don't have anything else, let's call it a wrap on our first show of Textron Gang. Just a quick reminder, again, predict is moving to Tuesday, January 14th.

Textron Gang will be on five days a week. We have, we're gonna be recruiting some new gang members for this year too. com and we have our producers contact you.

But, um, I'm looking forward to it and we have a lot of, a lot going on all around. So, Mitchell, Mike, Tracy, thanks for joining us today. Thank you for watching.

As usual, we've got Textron TV all day following our gang this morning, uh, until tomorrow though. This is Alan Shimo for Textron. Have a great day, everyone.

Happy New Year. Hey everyone, welcome to the Platform Engineering Show. com.

org. So we got all the platform engineering's here for you. What's up Luca?

How are you? I'm good man. How are you doing?

I'm good. Good. I see you're still in Morocco enjoying that Mediterranean lifestyle.

Good for you, man. Yes, yes. Um, goal is, goal is to show up at the Christmas dinner tant, you know, and make everyone else challenge.

All right. Well, you should be. You should.

Well, I would tell you, you could come here and get tanned, but our weather has been so miserable. I forgot what the sun looks like. We've just really in Florida and cloud.

Yeah, it's been very rainy, very cloudy. It's supposed to go down into the fifties this weekend, which is pretty cold for here. Yeah.

People are freaking out, busting out their coats. They're like, oh, it's nuts. I Don't have the, oh my God, it's so cold.

They're running to the stores, stocking up on water. It's crazy. Um, anyway, man, welcome.

This is episode two of the Platform Engineering Show. If you, if you miss the first one, it's available, it's available on Textron TV or YouTube or, uh, any of your favorite platform platforms of, of podcast platforms. They got Platform on the brain.

But you, any of your favorite podcast platforms like, uh, apple Podcast, Spotify, et cetera, um, in today's episode, Luca, what are we discussing? So we're talking about the salary gap between platform engineers and dubs engineers, um, where mm-hmm. You know, how real that is, where that might come from, um, and what that might mean, um, for, for where we're going as a space.

Absolutely. So I I, I told you when we were talking off camera, I have some interesting views here. Yeah.

Um, I'm not surprised that platform engineers are making more money than DevOps engineers. You know, when you saw, when I first, I Think this happened already once, right? Yeah.

Well, but here's the deal. com in 2014, there was a huge fight in the community. Like people like Patrick dubois and John Willis and, you know, some of the early a a, uh, Adam Clay Schafer, some of the early people in DevOps who said, there is no such thing as a DevOps engineer.

That's a fallacy. But in spite of that, the, the, the markets kind of decided there was such a thing as a DevOps engineer, right? And, and, and it's funny, Luca, when I first started a DevOps engine to be a DevOps engineer, you had to know Chef Puppet or Ansible, right?

Maybe a little J and maybe a little Jenkins. That's what a DevOps engineer. That was it.

And, and so did that define a DevOps engineer or did that define what DevOps teams do? No, but yet, right. It became one of the most popular jobs out there.

And where, where were most people coming from? Um, into the DevOps engineers rings OP for like ops, Ops, just ops people. Just the ops people, right?

Dev just Rebranding To DevOps. Yeah. They, you know, back then, and the DevOps was a different world back then.

Back then the devs used to say, you know, why I don't like DevOps too much ops, it's too ops centric. And you talk to the ops people and they'd say, you know why I don't like DevOps too. Dev centric too.

Dev centric, too much Dev. And, and so sometimes that's the, the test of a good compromise when each side thinks the other side got a better deal. Complaining.

Yeah. Uhhuh. Um, but I, you know, and I, I'll be honest, I went to both sides of this argument and I came to the conclusion that no, there is no such thing as a DevOps engineer.

That's a unicorn, a mythical creature. Hmm. That really, there are DevOps teams that are cross-functional, right?

That have security engineers and testing engineers and developers and you know, SREs and, and all of that stuff. Um, so I, I think the jigs up, I I think the market has come to the realization that what exactly is a DevOps engineer? Why should we pay them now?

Mm-hmm. I know a lot about DevOps engineers. I don't know a lot about platform engineers though, so tell me why they're real and why you think that's got legs.

Yeah, I mean, you know, we spoke about in the first episode last week, right? About this, the, the difference between platform engineers, dubs engineers, this like product mindset. Um, and, and, you know, our platform engineering evolved from DevOps, right?

Um, and I think that's really the, the, the, the key lens here, um, uh, to look at this as well, right? Because the way I think about is this, what we were discussing is apart from engineering is like this, you know, industrialization, right? Of how you, you know, basically build and deliver software.

Um, and, and this DevOp DevOps approach works in smaller, uh, teams in smaller settings, simpler, uh, tool chains, but it doesn't scale really well to like large enterprise, lots of people. Um, and so once you get to that scale, then that's the, that's the key thing, right? It's really about recognizing, well, we do need the operations of concerns.

Like that's a good thing. Um, you know, we had Kelsey Hightower at Recon 24 this year, um, and he did this Sari side chat with us, um, and he was saying, you know, if you tell people silos are good, it's a really quick way to get a lot of people in our industry really mad, right? Um, and, and it, and it shouldn't, and it shouldn't be, right?

They shouldn't be the case because silos are good. Um, you know, as long as you have the right, um, you know, the right ways of communicating between things, right? Um, and, and, and I think that was a very interesting insight for me last week from the conversation, right?

Of, of, of, you know, how you framed it, um, from like this historical perspective, das was kind of like this like revolutionary swing, um, towards like, Hey, everybody needs to do everything and so on. And I think that's really like the frame, the frame of this conversation for me is like, platform engineering is kinda like bringing back a little bit of, you know, silos. Not to the extent where like, Hey, we just throw over the fence the code and like, we don't care about it.

Um, but you need some level of separation of concern to be a productive engineer organization at a certain scale, right? If you're 10 people, great, everybody knows everything you can do. DevOps, fantastic.

If you are, you know, 2000 people, you just can't take the same approach, right? Um, yeah. 10,000 and so, and so that's really the, the, the, the thing.

And then I think, you know, to your point, what we're seeing is, um, and, and so I do think that the platform engineer role is more legitimate, if you will. Um, and I hope people are not gonna clip this, uh, than doves than the doves engineer role, right? Because, because ultimately, um, to your point, like DevOps is, is a, is a methodology, is a practice, is something that we do as a team, is not, it shouldn't have been a role, right?

That that's just because the market evolved that way. Whereas platform engineer is a very specific role, and I think it's actually very important to, um, define it precisely because, um, one risk is that the same, like a very similar thing happens again, which is like, okay, now the das engineers rebrand to platform engineers and they don't change anything, right? And they approach building a platform the same way they're used to, you know, uh, uh, building and managing infrastructure, which is a one and done six months infrastructure project.

That's not how you are supposed to build a platform. The platform is a, um, you know, something that is a product. It's, it has a life cycle of five plus years in, in most enterprises.

And so that's really how you should approach this as, as a product. Um, and, and so that's one of the, the key differences between DevOps and platform engineers is this like product approach, product mindset. And, and so that means that you have a very differentiated role from for exam example, INO teams, right?

Like infrastructure and operations teams. Like they're, you still need them, right? You, you need both.

And then of course, you know, in some companies, platform engineering becomes this, like I was just talking to like a large financial institutions half an hour ago, you know, where like platform engineering is like this huge umbrella term that has INO teams that has like cloud ops, it has SE that has everything underneath it. But whether, you know, regardless of what your end, the, the, the end sort of like org structure looks like on your, on, on your end, it's important that that platform that the platform team has its own sort, like mission and role, which is building a product, is not maintaining the infrastructure that that product runs on, right? And so that's where, you know, INO teams are still necessary.

That's where SREs are still necessary, right? It's not that like platform engineers, uh, replace any of these. It's more augment them, um, and really bring that, uh, product perspective into the, into the equation.

Yep. Few thoughts on that. So first of all, I don't know if you're familiar, there's a show on Apple tv.

It's in its second season now, it's called S Silo. Did you ever see this show or hear of It? No, I haven't.

No. You should check it out. It's called Silo.

So it's a sci-fi series, right? Uh, and the idea is something happened on earth, the earth is poisoned, you know, typical sci-fi stuff, the earth is yeah. Poison, toxic, and people live in a silo.

Like there's a silo that goes way underground. And this like whole society lives within this silo, and the silo somehow filters the air and it doesn't, and it's a hundred years or hundreds of years already, and people are just living in this silo. And then some woman did something wrong and they exile her outta the silo to the wastelands.

And she goes out there, you know what? She finds other silos. And so it turns out that there's all of these silos out there where humanity is survived, but they don't communicate other, and they're not aware Of other That is funny, right?

And so they don't, and they don't, you know, one silo is all dead 'cause the catastrophe happened, or a something, you know, a virus outbreak, another silo is doing really well, another silo, not people are starving. Where, right? Had they had to, you have all the different Like branches, right, basically, right?

Yeah. They're all like little Petri dishes, but had they had communication, the whole would've been better, right? Maybe they could have reclaimed the earth or something by then.

It's the same thing here, right? When you have silos, it's okay if, if you're a platform engineer and you're doing your job, you're not a developer, you're a platform engineer, and a developer is a developer, it's the communication that's the key. And that, that was really the part about dev.

Like if you speak to Patrick Dubois and, and some of those folks mm-hmm. It was about the communication. Mm.

It wasn't about the title, it wasn't about being a DevOps engineer, it wasn't about knowing everything. It was about the communication working together, right? In, in sort of harmony, if you will, to accomplish the common goal.

You said something last week too that I thought was, was really dead on, which was, we can't expect developers to be responsible for building their own platforms, right? Think about that's like saying, Hey, you wanna live in this house, go build the house, then you could live in the house that might have worked like, you know, in, in the, in the American west, in the 18 hundreds or something. It was Very simple house.

Yeah. Like Then yeah. Right?

And if it's a locked cabin, that's not the way modern software works, right? You can't tell someone go build their own house and then you can live in the house. Yeah, exactly.

People wanna buy the houses. And this communication and this communication thing, I think is super interesting, right? Because I, you know, we, we spoke about this like product mindset as kind of like one of the key sort of differences between the, you know, this like doubs approach and like the platform approach.

But, and, and one thing that also always comes up is this also like communication thing, right? Um, and I think it's very interesting, and I think it speaks to the fact that like, despite the original, uh, intentions, this, this communication focus was really lost in the, in the, in the, in the, in the, in the DevOps world, right? Because, you know, now people are looking at platform engineering.

And when I, every time I say yeah, like, you know, one of the key skill sets of a platform engineer is, is communication, right? Why? Because you need to mediate between all the different, you know, vested interests, basically.

All, all this in stakeholder groups, like you need to make the developers happy. You need to do, you need to make executives happy, you need to make, uh, the IO teams, the security, the architects, everyone happy. You need to get everybody on board.

And you need to be a really strong communicator to do that because the way you speak to the value of the platform, uh, you know, to developers is completely different than when you do it to, um, you know, executives. Like, you know, developers are gonna be about waiting times and security teams are, is gonna be like enforcing compliance automatically. Executives are gonna be about time to market.

If you talk to developers at downtown to market, they're not gonna care. Right? So, um, and, and so that, and so that's why you need to be a really strong communicator.

But I think what's very interesting, you know, on, based on what you just said is, is this right? That, that, like, people are very, like, every time I say this, people are like, yes. You know, everybody just like nods and is like, wow.

Yeah. Like, you know, as if it's like a revolutionary concept, right? Like, except like it was the same thing in DevOps to your point.

It's just that it got lost. Yeah. It, it, it got pushed to the side, you know, with this whole, with people wanting, you know, hire DevOps engineers, frankly, right.

Where the real DevOps people knew that a DevOps engineer was kind of a squishy thing at best. Um, but let, let's talk about platform engineers. Europe versus North America for a second, right?

Yeah. I mean, yes. The US or North America, you know, meaning Mexico, Canada as well.

Um, I mean, generally it's a bigger market than let's say the EU market. Um, and I I, but there's usually a little parody I, I know in like developers, software developers. Yeah.

If you get big discrepancies, let's say between Eastern Europe and Western Europe, Northern Europe, Southern Europe, we have it in the US too. A platform engineer or a developer in the, in the Bay area in San Francisco makes a lot more than one, you know, in Atlanta, let's say. Right?

Atlanta has relatively lower level, but is there a big discrepancy in salaries, but still between EU and, and North America for that? Yeah. Yeah.

So we, we ran the survey, um, across hundreds of, of, of platform teams, um, and even more individual contributors. 'cause we both asked DevOps and platform engineers, um, you know, how much we make and the numbers are, um, considerably lower. I wish I could show the slide, maybe like, you know, we can show it later, but, um, yeah, Yeah.

Or link It somewhere. Yeah. Maybe we could put a link to the, well, what we should do is put a link to the whole report where people can download it.

We'll, we'll have that. Yeah. org.

But the, um, you know, what we've seen is, um, there is a, a probably like a 30 40% gap between, uh, sort of like North American and Europe, both in platform engineer and DevOps. Yeah. And then for example, so consistent.

Yeah, consistent. So for example, the baseline for, uh, Europe on platform engineer is 120 grand. Um, and, and it's about like a hundred for DevOps.

Um, on platform engineer is almost 200 grand on, uh, platform engineers, uh, for, for, for North America and for DevOps is 150, um, for, uh, in Europe, right? So, um, platform engineers is higher on both. So about like 20, 30% higher than DevOps engineers.

And then North America is higher on both of those, um, on both of those numbers. Um, and, and, and this is, by the way, I don't know if you've seen, like lately there's a lot of, um, like on x there's a lot of people like posting this, um, this delta that developed between like Europe and the United States, because to your point, well actually Europe is a technically a bigger internal marketing internal market, right? Because they have Right.

Like, it's like 500 million consumers instead of like 300 some, uh, but the 30 Yep. Yeah. But, but the, but if you look at like post, um, uh, GFC, right?

The, the great financial crisis too in, in oa, like, it just, they complete dive average like up until there, you know, in the nineties and so on, were kind of like Europe and, and US were like growing at a similar pace. US was always a little bit higher, but not that much since then, basically Europe flatlined and then, you know, US has gone vertical in the last 10, 15 years. Um, so it's super interesting to see, um, and, and that, and so, and, and then people kind of like always, you know, in this threads, like break it down in terms of like, even if you look at like, really, like, I think it workers, software engineers, it's so much, it, like they're, they're the, the, the delta is huge, right?

Like, we're talking, you know, I was just talking to like a, a really good product team actually in the platform engineering space in, in Portugal. Um, they are pre-seed, probably like few million something that they raised. Um, and they have like 15 engineers since like a year, right?

Like, this would be impossible to do in like New York, Or you couldn't do it. Yeah. No way.

No way. And so, and so I think like up, and so in some sense it's, it's not a bad thing, right? Because from a startup cost perspective, it's, it's, uh, it's easier.

But, you know, broadly de definitely you can see there's like a big gap. And, and I mean, Europe is, is being smoked right now. We're really just being left behind.

Well, you know, so I I, I read this whole series of books by a guy named Thomas Friedman who writes for the New York Times. The whole like, I dunno if you ever heard The World Is Flat, is a book he wrote. Mm-hmm.

And then he wrote, yeah, it's a flat hot world and it's flat, this and that. My my thought is, especially when we're talking western Europe, right? It's not the stone age.

There, there is technologically advanced, I think, as most of the us and that's why I'd love to see the, the numbers like, is it maybe that platform engineering is a relatively new discipline. And so most of the platform engineers are based like in the Bay Area or New York and Boston, where yeah, you gotta make 200 K just to live. Mm.

Right? 200 K iss not living high on the heart in New York. The geo bias New, right?

The geo distribution bias, right? Yeah. That's interesting, right?

Mm-hmm. But, but what's a, what's a platform engineered Dallas making, or Atlanta, or Charlotte or Miami, or, you know, where mm-hmm. Cost of living is a little less than New York or Boston or San Francisco.

And, and maybe there's just more platform engineers concentrated there because they're more, um, tech savvy. They're more advanced technologically. You don't have, I mean, heck, I'm trying to get a social media person down here in South Florida who has B2B and tech industry experience.

And I can't find one really. I can't find one because they're not, well, I can finds plenty, plenty of social media people. There's no tech.

Mm-hmm. Yeah. I've got plenty of social media people applying who have done makeup companies, real estate companies, financial advisors, um, you know, all kinds of crazy stuff like this.

But not, not in the tech space. 'cause they're not here. Um, right.

And, and supposedly Florida's getting very tech like Miami, they want to do Silicon Beach and they're doing all these things. Mm-hmm. But we don't have that community that you have in New York or Boston or San Francisco or Austin.

Right. Um, and I wonder if that's not part of it. But the other thing from the flat earth stuff is, look, if it's that much cheaper to go to Portugal and get a platform engineering team team, and I'm a startup guy, and I say, okay, I need a platform engineering team.

I could do it in Portugal for half the price. Yeah. I'm gonna do it in Portugal for half the price.

I gotta be stupid not to. Right? Yeah.

It's the whole reason why India has an IT industry. 'cause it was half the price or less Yeah, right. To get engineers and, and That's happening, right?

Like if you look at like Eastern Europe, like there's a huge, and there's a, and it's interesting because while, to your point earlier, it was, I think it was mostly just like, okay, you know, western Europe more expensive, which is higher in Eastern Europe. I see now a lot of actually US based companies just hiring in Europe and Eastern Europe because, you know, it, it become like, as everybody becomes, you know, more used to the whole remote thing, um, it's, it's like, of course, like, why wouldn't I do that? Or, or even Canada, I mean, even Canada, you know, you're like, up in Canada from like the West coast is already a lot, a lot cheaper than, than if you're in, if you're in sf, right?

Um, sure. So for sure. Um, but, but I think like on the, on the Europe side of things, what's, you know, the problem is, is, is, is is also just like, you know, you know, we, we said like, okay, well this is this, this large internal market, but actually it's, it's not true because you need to like re re localize every time your product, your service, whatever you do.

Not just from a language perspective, but from a regulation perspective. And it's really like regulation that's killing it. Right?

Um, so, So that's a whole nother episode we should do, which is, especially with the new administration coming in here in the US and, you know, the, the, the, the government of Germany just had a no confidence vote and got right wingers in Italy and, you know, is the world entering, you know, I grew up in the, we should have no trade barriers. It's a small world after all. Mm-hmm.

And, you know, and we should, and then that, that's the best thing for everyone, right? Bring, bring American style, lux American lifestyle to the whole world. Let everyone be consumers.

And that would be good for everyone. I don't know if it turned out to be so good for everyone, but, but the bottom line is like free trade, right? Let the best country win.

Let the best engineers win. If it's cheaper in Portugal, do it in Portugal. But now we're entering I think another era where people are putting up tariffs and barriers and it has to be made here and supplied.

You know, it's under change security. We're gonna make sure we have the ability to make our own chips here and make our own silicon here and make our own. Yeah.

I don't know. And it's not the us especially with this new administration, you're gonna see a lot of that. I, but I think you're also gonna start seeing it in Europe too, right?

Yeah. War probably more Probably. We, we tend to follow, right?

So it's interesting. Yeah. Going back to The side.

No, I, you know what I, I think it's actually been in the year and this move to the right has been in Europe. I think US is a little later to it, right? If you look, I mean, well, UK went the other way.

UK has a labor government now. But I mean, you go to Greece, you go to Italy, you look at what's going on in Germany now, even in Israel, which you know, is kind of EMEA and I mean, these are right wing governments that yeah, we trade isn't isn't their calling card, it's protect our industry a hundred percent. And so I, I think the whole world's doing that.

The whole world's going this way. And what does that mean for us? I, you know, like I said, that's a whole nother episode we could talk About.

It's hard about, but it's very interesting, you know, a game theory perspective as well. Like when that, because Yeah, yeah. Like if one starts, then the other one goes like, it's, it's interesting thing.

Um, Ed for tat Yeah, exactly. Ed for tat you know, I just, what did I say? China just launched this week.

The, the first, so basically, you know, Elon Musk satellite, the internet, right? The, I forget the name of it now, his internet visa. I have one starlink China.

So China is launching their own starlink. They wanna put 14,000. Oh, I didn't know.

Yeah. They just sent the first batch up this week. Now.

Interesting. They didn't do a lot of publicity around it, probably because they copied some copyrighted stuff or whatever. Who knows with them.

But, you know, but they're, they're, you know, so now you're gonna have competing satellites and they, it's gonna be interesting times over the next 10, 20 years, I think is kind of the world kinda readjust. Readjust. Oh yeah.

Um, so platform engineering salary. What about compared to developers? Yeah, we got, we, we we got astray a little bit.

Um, so, you know, like in general, um, I think, uh, I have an interesting data point here. Um, 'cause we asked people also just like how senior they are, uh, in the survey, uh, which I think was very interesting. Um, and, and this will kind of explain, right?

Like the, the, the gap between the, you know, between platform engineers and developers is pretty high. Um, and the reason is that, you know, platform engineering ultimately is not an entry job. Right?

Whereas developers, it could, you know, normally it is, right? It's, this is where you start and then you're a junior developer and then you go up. Yeah.

Um, and you know, so we, we were breaking it down. Uh, so out of the hundreds of people that we asked, only like less than 5% has less than two years experience. 15% has three to five years experience.

34% has six to 10 years experience. 18% has 11 to 15, and 28% has over 16 years experience. Right?

So, like, you know, if you look at this, basically something like 80% is at least above six, six Years, or six or more years. Yeah. And then basically half of them is more than 10 years.

Right? So, so that tells you A lot. So how do you, so how do you grow new platform?

So this raises an interesting question. There's a gap there. Yeah.

Right? There's a Gap. How do you, how do you, how do you grow new platform engineers, right?

Because the, getting them to that six year mark is, is hard, right? This is the old, you know, I want to get my first job. Well, you gotta have experience before we could give your first job.

Yeah. Yeah. It's a catch 22.

You know, how do you, how do you overcome that? Or is is that like a cliff we gotta worry about? No, I think that's a great, this is super interesting, right?

Because also, and the other, the, the point that's in the report is like right after that is, is then you look at the, the average age of the teams, and obviously it's way younger, right? So, you know, it's like, it's like, uh, 10% is zero to six months. You know, over, over half is like under two years, right?

Um, and only like 10% is over five years. So what that tells you is like, these people of course are, um, you know, they have a lot of experience. They don't necessarily have a lot of experience.

They're as software engineers. Yeah. They're recycled, right?

So from DevOps, from other cloud ops, access, three other things. And so, um, and so I think to your point, to your question, right? Like how, like there's definitely a shortage right now, I think in the market.

I wouldn't say the shortage is, is necessarily in, um, people that are able technically to build a platform. I think the shortage is in this, in people that think with this product mindset, right? Um, and an actual like, you know, brought up managers for platforms is a huge shortage.

Like I see it, whether it's on our products pipelines, whether it's on, um, you know, general companies that I consult with. Um, you know, even the very large, you know, people that I partner with like ThoughtWorks and like, you know, very large providers, they even have a shortage internally, right? So they have like all this like pipeline.

Um, there's a lot of demand in general, I think in the, in the, in the market for platform engineering. There's just not enough. And there's enough technical people that can build a platform.

There's not enough product people that can actually drive the, like, you know, good platforms basically, and not platforms that nobody adopts or that they're actually missing the point, right? Um, and, and so, and so I think the solution there is twofold. One is just more education for everybody, right?

This is where why we rolled out the courses and the trainings. And it's really about like raising all boats at the same time. Because, you know, you made a point earlier of this, like dubs engineers this like, uh, you know, unicorn.

Um, I also think this like technical platform product manager is a, is is maybe not a unicorn, but very close, right? It's, yeah, it's very, very hard to do this, right? Like, how can you be like technical enough to, you know, spar with, you know, people that have 16 years experience building these things.

Um, but at the same time have the soft skills to, you know, communicate with like very, um, you know, high level with the, you know, very senior executives because these are very large companies, but also like low level developers and figure out what they want. Like, I mean, this is just like, and Then that's a very unique skillset. Yeah.

And you have very few of these people. And then what you see is, uh, enterprises, when they recognize this stallion, they're like, no, no, no, no, you're not gonna work on an internal facing product. You're gonna work on a external facing product.

So I'm, I'm gonna put you on the internal developer platform team, right? Um, and so, and so that's where the shortage comes from. And I think it is.

And so I think for me is, yes, we need to train more of these people and build them up, but I think it's the, the short term solution, short to midterm solution, um, is actually take you, you know, all this like existing people that have a lot of experience and make sure that they adopt some basic understanding of this, of this with this product mindset, right? Um, you don't need to become like a super proficient, you know, technical product manager. You just need to, you know, understand, Hey, what is platform engineering?

Why are we doing this? You know, and, and, and like, who are our customers? Our customers are developers, right?

You just need to have a bit, you know, switch a little bit that, that's really like customer centric focus and product centric focus when you, when you build your platform. And I think that's gonna get us 80% of the, of the way there. Agreed.

Hey, as long as we're getting stuff off our chest, I got another type of engineer. I wanna ask your opinion on uhhuh. And that is the, the so-called full stack engineer.

So is there really such a thing as a full stack engineer, have full stack engineers, become platform engineers? Was there ever such thing as a full stack engineer? God knows they were hiring enough of 'em, right?

And they were paying them good money, but what, what's your view on full stack engineers? Well, I think it's, I think it's, from my perspective, it's just interesting, um, to see this industry, um, just how, or how much, you know, developers say they hate marketing, how quickly they fall into marketing things, you know? Um, and I think like full stack is just like another example of this, right?

It's like, you know, the same thing of like, people that create that said, Hey, there shouldn't be a devs engineer, and then everybody falls into the south engineer thing, right? And it's just like, um, I think it's, um, you know, all these titles, you know, I was, I was listening to this podcast like a few months ago where this guy was basically running growth at Facebook back in the days, and he was saying, you know, we needed, um, data scientists except 'cause we had a lot of data to analyze all these things, except the, like, data scientist wasn't a thing. They created it right before it was called some sort of business analyst.

Like, something that, that sound boring basically, right? And they're like, no, I need this PhDs, right? That, you know, and I'm gonna pay them a lot of money.

But the problem is, if you package this as like, you know, a like a business analyst, nobody's gonna come, right? And so they were like, oh, you know, they all come from like physics and things like, they like the science thing. So I just call it data science.

They literally, that's why. And you know, and now you have like, you know, all this curriculum in, in curricula in, in, in, in, in universities of like data science. But like the, the actual data science thing was invented by Facebook as a way, as a hiring tactic, basically, to Make it sound sexy.

It's marketing To make it sound sexy. And so, like, you know, a physics PhD would go and like, do become a data scientist because it's cool. Um, and they paid you a lot of money.

Mm-hmm. Um, and, and so I think it's like, this is a bit of the same thing, right? Where like somebody just figured out, you know, I mean, I had the same thing at some point I had to hire, um, somebody for growth as well, and I was, I had this like, demand generation lead and I was getting really bad applications.

And then at some point I just put like, out of growth. And then like, all of a sudden, you know, it's like all this like small tweaks that you make, um, um, um, you know, so maybe there's one for your, uh, for your, uh, for your social media badge. Oh, stack.

Um, Yeah. Starts for my, I I've thought about how do I make that social media thing sex? That's a whole nother story.

Yeah. Anyway, look, I think it's, it's just about we're over time people making a sex too. Hmm.

Yeah. It's, it's marketing my friend This Mark, We're outta time. Hey, we, we will be, we'll be, this is our last show for 2024.

Our next one will be 2025. Um, we also have some webinars or round tables around the platforming show coming up in January. We will be publishing all of that, I guess, in our social, if I could get a social media person publishing all that in our social media, uh, stuff.

But this has been a great conversation, man. Enjoy Morocco. Have a, a happy merry Christmas Luca and a happy New Year.

And to everyone watching or listening to this Merry Christmas, happy New Year to you as well. And we will be back in 2025. We're just getting started with the platform Engineering show care.

Yes. Thank you. Happy holidays.

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

Alrighty. Bye-bye. Modernize your business to fuel innovation and elevate customer experiences with the builder community.

Hub AWS and its partner network provide essential tools for transforming applications and infrastructure to fully leverage the cloud. Discover free trials, in-depth demos and essential resources to empower DevOps engineers and developers to deliver value faster and more reliably. Visit the Builder community hub to learn more.

Hello and welcome to the digital CXO podcast. I'm Amanda Ani, and I'm excited to be here today with Siram Naga Swami. He's the executive Vice president of Four Kites.

How are you doing today? I'm good, how are you? Doing well.

Can you share a little bit about four Kites and what services do you provide? Sure. Yeah.

So Four Kites was started, uh, almost 10 years ago with, uh, the primary purpose of answering the question, where is my shipment and when will it get to its destination? And, um, I mean, this is what now, in today's world, we called, uh, we call real time transportation visibility. And, um, uh, you know, focus, uh, created this, uh, entire, um, uh, genre, uh, of real-time transportation visibility.

Um, so we started off with answering those questions, and then we've obviously moved on into orders and, uh, now obviously AI and so on and so forth. So, um, uh, you know, so we are, we are more trying to, um, uh, go broader into the entire supply chain and provide visibility in all the processes of supply chain and to end. Wonderful.

So can you share some use cases for your technology in the supply chain and, and what impact is it having? Sure. So in fact, um, as recently as yesterday, right, we had a very, very good call with the customer.

So one of the primary use cases, uh, that more and more people are, uh, are definitely seeing a lot of use from forkites is our disruptions dashboard. So supply chain, you know, one of the constant things about supply chain is that there is some disruption going on somewhere or the other. And, um, you know, we have, uh, a disruptions dashboard that clearly captures all the disruptions, right?

Like, for example, it could be the Baltimore Bridge collapse or the Red Sea event that's kind of ongoing, where vessels have to route around the cape of good hope to, uh, not pass through the Red Sea. Um, uh, so as Canal. And, um, so these events add uncertainty to, you know, a shipper's supply chain because they don't know when the container is going to reach its destination, and they need to take mitigative actions that will ensure that in spite of some of these events happening, you know, how can they make sure their inventory is, you know, on target to fulfill all the sales orders that they have.

So these disruptions we provide, you know, um, uh, as early as possible all the impact areas that can potentially get affected. And, you know, we call out all the vulnerability zones and their, and their containers or their tra their shipments, which can potentially get affected by a particular disruption. Now, for example, on everybody's mind as the ILA port strike, which could potentially happen in Jan on January 15th.

So we've already started, you know, um, surfacing that on the platform on all the ports that ILA currently manages, and, uh, where if shippers have certain containers that are estimated to arrive beyond Jan 15th, they could be potentially affected. So these are some of the use cases. And then, like I said, you know, our predictive capabilities, which is our ets, uh, which route to take certain recommendations, um, basically are ML and AI features.

These, these have been proving very, very helpful for our customers. From your experience, do business leaders need to be more concerned about disruptions this time of year during the holiday season? Are there more of those, uh, during holiday time?

Um, I think there are definitely disruptions, I think throughout the year nowadays, I think that's more of the norm. Um, the specific reason the holiday seasons, uh, it's, it's way more critical because the impact is a lot, um, larger, right? Like during a quieter season, you know, one container or two containers coming in, coming over, it's not gonna cause as much of an impact as the holiday season because definitely, you know, during the holiday season, everybody is looking, uh, to make sure their inventory is up to, uh, the levels that they want it to be.

And, um, any kind of disruption there causes, uh, you know, like a huge impact to, uh, the organization. And that is the reason, you know, uh, during the holiday season, people are a lot more concerned about disruptions, uh, because that does definitely, uh, play a huge, huge impact as, uh, you know, the demand as the highest during this season. Absolutely.

So one of the biggest technology topics of this year, the past couple years is of course ai. So how does forkites, uh, use ai and can you describe the impact AI is making? Sure, absolutely.

Um, I mean, just in one word, uh, AI is revolutionary, no question about it. Uh, specifically gen ai, um, uh, we have been on this, uh, journey of incorporating gen AI into our platform for, uh, more than a year now. Almost, uh, one and a half years is what I would say.

Um, in fact, uh, I think it was August, 2023 when we released our, uh, Finn ai. Um, so it can answer questions, um, you know, that customers have about a particular shipment, uh, a particular port, a particular facility, uh, particular, any particular asac. Uh, so it can gather, you know, data from within their network and present it in simple, understandable English.

And that has been a huge hit amongst our customers. And we see the usage of, you know, AI on our platform increasing on a, on an everyday basis. And similarly, whether it is internal use cases or external customer facing use cases, we are seeing AI grow on an everyday basis, uh, very, very clearly.

There's a high demand and both internally and externally. And that is something that, um, uh, you know, we are, uh, uh, uh, from a customer perspective and from, you know, just from a pure development perspective in engineering, we are seeing that, um, you know, more and more people, um, on a daily basis are adopting, uh, AI for their day-to-day work. And it does make, uh, uh, you know, uh, it has absolutely made a productivity go through the roof.

There's no question about it at all. And similarly, like what, uh, impact it has had on our productivity, I'm pretty sure our, uh, shippers are also seeing a similar impact on productivity on their side using some of our AI offerings. 'cause that's, that's exactly the way we see.

And the biggest thing is once you deploy AI to a particular task, it's practically 24 by seven, three hundred and sixty five days. So, uh, that, that efficiency is just unmatched at this point of time. So, looking into the coming year, 2025, as as this AI advances so rapidly, do you have suggestions as to what IT leaders should be looking forward to in regard to AI and the supply chain?

Sure. Yeah. So I think one of the biggest advantages of AI is going to be that the traditional integrations are going to go away pretty soon.

Um, you know, integrations with external systems are going to get a lot easier, and IT leaders have to, so previously, you know, integrating to an external system, which would be a three month or a six month project, those can completely vanish now, and it can, you know, any external system of interest, potentially one day to one week, depending on the readiness. So I, I think the more and more IT leaders and supply chain, uh, firms embrace ai, I think they will see that some of the traditional tasks that they, you know, always feared, right? Just because of the complexities involved, those are going to become things of the past.

And, uh, you know, so that is going to help through inter flowing of data, which would essentially lead to more and more innovation and more and more efficiency. And, um, I would, I would, uh, say that that would be the biggest advantage. And of course, like I said, you know, there are certain workflows that, uh, uh, you know, today that just repeatable tasks, right?

Those can completely go away with ai, and AI can take over those tasks and, uh, and pretty soon it will. And, uh, you know, this is going to definitely, again, revolutionize some of the supply chain, uh, uh, that some of our shippers are seeing today. Yes.

And I'm hearing and reading more about AI being integrated into robotics too, within the manufacturing and supply chain, Right? No, absolutely. The, that's, that's the, uh, point that I stated, right?

Like anything that has a repeatable task with a one-off where, you know, AI has to make a decision on the fly with context, and then just continue that previously, what it was just called as robotic process automation, right? Whereas now we are truly moving towards intelligence process automation, where depending on the context, even the decision can be made and the right folk can be picked up. And that is causing the biggest change.

Where, you know, we are very clearly seeing that some of these decisions can very easily be made by ai, and we don't need a human in the loop. I mean, the human in the loop is just to verify the action till the trust in the AI grows. That is definitely going to be 2025.

Well, if there was one key takeaway you could leave our audience with today, what would that be? Um, I mean, my biggest, uh, thing would be that, um, uh, if, if there is any resistance to AI in any of the organizations, I would say absolutely, uh, please embrace AI as much as possible because this is the future. And, uh, you know, having spent about one and a half years with it, it is going to make a lot of things efficient, but it's not just going to take away systems to end, and there are going to be human interventions.

And, um, I think overall at the end of 2025, we will clearly see that the people who embrace this revolution will be more successful. And that would be my one takeaway, where, whether as an internal project or external, uh, assistance, uh, that people definitely start embracing AI more in. All right.

Wonderful. Well, thank you so much for coming on our show and sharing your insights with our audience today. Cool.

Awesome. Thanks. Great.

And thank you to our audience. Stay tuned. There's more.

Hey, everyone, welcome to, um, a, a very festive, uh, episode of From the Source with your host, uh, Nan. And I'm Brian Fox. And Brian, um, we've got a very festively, cheery, uh, topic that we wanted to touch on today, but should we, should we do one of these or work?

Oh, yeah, yeah. Good. Oh, yeah, that's a great idea, actually.

Let's get distracted, uh, just for a moment. Ho ho ho. Nope.

Can't, can't get it to work. Well, um, so Brian, we got a bit of a spicy topic, uh, that, uh, I wanted to touch up on today. Um, and in fact, the synopsis that we've got going on in here, oh, look at that confetti.

Love it, love it. You're getting in the, in the spirit of things. Well, uh, just in time for the holidays, uh, a little bit of something for the, um, uh, for the, um, uh, holiday table discussion why SCA isn't enough.

So, you know, this is something you and I talk about constantly. It's been, you know, something that I feel like we've been saying for years in one way or the other, but, you know, good software supply chains are under a constant threat. We're, uh, we are seeing, you know, huge amount of new threat vectors, uh, entering into their amount of risks from just technical negligence managing it.

We're seeing, uh, you know, attacks, uh, being executed, leveraging it, and from one paint place to another. And because of all of these things, people often see SCS or the silver bullet. And, you know, the reality is SCA totally is not a silver bullet and solely relying on it, uh, is not sufficient.

So the topic that we wanted to touch on today was really to do a little bit of a deep dive on, um, what that means and why that means. And I'm, I'm gonna start us off, Brian, with a little bit of a controversial statement. I think most people kind of use SCA as a bit of a, a pressure valve and, and a bit of a sort of thing to, uh, to say, Hey, I am doing something without actually doing much at all, because the thing is alerting me, and therefore I'm safe, even though I don't address any of those alerts.

But, uh, look, Brian, you've been thinking about this a long, long time. What's your thoughts there? Yeah, I mean, I'm a little bit on the fence.

I mean, I feel, I feel like a big party industry isn't even doing a ca as evidenced by the fact that so many people still use, uh, known vulnerable versions like the Log four J that we've talked about in the past, that they keep using the vulnerable versions. And I don't think that's an intentional choice. So, um, there, there are shades of people are doing it, not doing it, doing it a little bit and ignoring it.

Um, you know, and, and I think you, you, you almost have to explore that a little bit. I mean, clearly, uh, the angle we've always taken is, uh, just doing the analysis is a little bit passive, producing reports that are summarily ignored by developers. Does it do any good?

And, and that's why we've always tried to, you know, be deeply integrated into the pipeline so that you can actually define guardrails for your developers, uh, break bills, block releases when you have to. Hopefully that's a last resort and not the first move, right? So, you know, I think, uh, traditional SCA, if there is such a thing, you know, um, commodity SCA is really just producing reports.

So clearly an element of you need to do more, can be thought of as, you know, you need to think about it as a supply chain, get integrated, be able to provide the, the information to the developers when they're making these decisions upfront, not, not scan and scold as we like to call it later, right? That's definitely an area. Um, you know, and then there's, there's going beyond that in terms of being able to address malicious components, right?

So those are, those are kinds of the things going on, uh, in my head as I think through this, this Topic. Yeah, I mean, it's a tough nut to crack, but, you know, let's take a look at some facts. Um, you know, one of the reports that we've been publishing, we've just released a sort of malware report where we do a deep dive, uh, into sort of the malware distribution.

We'll, we'll touch on that a little bit later. But, um, is the state of the software supply chain report we did, we've done a number of deep dives on, on the show, uh, about that. And, uh, you know, one of the things, if you just look back 10 years that kind of stands out is really, uh, the fact that there's actually been not so much changing behavior in terms of vulnerability c consumption.

So like you said, people still download vulnerable versions of Log four J period, vulnerable versions of Log four J to log for shell to be specific. And that is literally the most published as security benefit o of all that. There's like literally no excuse to be downloading it at all in the first place.

And, um, and then when we, when we kinda look at sort of the technical reasons as to why that's happening, part of me is ignorance as in not doing, uh, SEA at all, any, any kind of activity. And part of it is also sort of, Hey, we will accept the risk and we'll do that. I think part of it is also technical, you know, a lot of sort of what you just referred there to as commodity SCA, really the only thing that it does is compares, um, in dependency manifests, you know, Palm XMLs package files, uh, package logs, things like this, uh, to a public database of security vulnerabilities that, you know, may or may not be accurate mm-hmm.

To the level of information that's needed to get an accurate reading. And, you know, kind of early days of SCA, the biggest hurdles that we people always had to overcome was the fact that it was super noisy. It was super full of false positives.

And I think to this day, if you use something like, uh, something like depend upon or other, other tools like that, you're still inundated with sort of false positives because it feels like it ought to be a very simple problem to solve. I've got a list of components, I've got some database left join, that's my things to fix. And, and, and that's literally it.

But it turns out there are no good databases. The databases have to be built by vendors such as ourselves. Uh, there are no good ways of actually matching dependencies, uh, from just manifest.

You have to look at the files, the installations, the, you know, and it's different for every single programming language. And that leads to a situation where I think a lot of people, even when they are doing S-C-A-S-C-A through some tooling or another, aren't actually really doing anything that's impactful, aren't really reaping the benefits because they're not really truly covering all the risks that that's there. And even worse, they're sort of drowning in things that aren't actually necessary things that you needed to address in the first place, which unfortunately us all being engineers in this industry, we just down this path of, well, I'll find a way of filtering those things out.

I'll find a way of looking at my call path or what kind of going down the execution flow of the application to try and skim down that sort of poor result set that I have into something that I can at least action. So, so I think a lot of the, a lot of the issues that we see, the in effect that we sort of observe are actually sort of very technical in nature. They're, there are things that, uh, that, uh, people do, but there's also sort of, I feel like a human element thing.

Um, and I think it's sort of the ostrich problem, which is, Hey, if it isn't the most critical thing in front of me right now, I'm just gonna ignore it. 'cause hey, it, it ain't broken and it hasn't come to bite us yet. And that, that's sort of, I think the same analogy as blood pressure.

You know, it isn't a problem until it becomes a real problem. Yeah. And by then the damage is done.

Yeah. I mean, the, the thing that I see this happening a lot is, is of course, within the malicious open source components, right? That for organizations that are doing some form of SCA, they, they often think that that's gonna handle the malicious component because they're thinking about, well, I don't want these bad things to be shipped downstream to my customer.

But the problem is, that's not the goal. The goal is to attack your developers and the development infrastructure. Um, and so if you're scanning these things after the fact, the damage has already been done, right?

These components leverage, um, the post install scripts and things like that, and NPM and Python or, and what have you, and fire, as soon as the developer downloads and installs this. And, and so the, the attack happens at that moment, not after you build and release the software. And so if your SCA process, even if it's deeply integrated into the infrastructure, the pipeline might not see it.

And if it does, it's still after the attack, right? So that's part of the problem that, that I think, um, for, for many folks, they're conditioned to think about, okay, these are dependencies and I have a process for managing my dependencies. It's like, yes, but this attack is happening far left in the process.

And so you need different types of defenses to catch and stop those. The only way to prevent it is to intercept that request and make sure that it doesn't land on the developer's machine. And that's a very different dynamic that I think, um, is getting lost in the noise of SEA.

Yeah. I, I think you're absolutely right. And, you know, one of the other sort of things about SCA is it is a useful tool for the job that it was originally designed to do, which is to enable you in flight, during an engineering workflow, make better decisions earlier, and then give you some sort of gating to make sure that you know, hey, if some decisions that weren't great were made, uh, you can, you can at least prevent them from going forward in the process because kaizen, you know, pull the Andon code, stop there, you know, and, and, and fix the issue, the, the problem or agile manufacturing for that matter.

But the problem there also is it ignores a problem on the right hand side, you know, so we certify something today as good, you know, it's gone through a scan, uh, et cetera. We, we ship that out. Even if we continue to build and we continue to throughput things, that doesn't mean that the thing that was shipped out the door is still good.

Um, because that in on itself might have different things. That's part of the reason why we've had this introduction of, of all the SBO laws as a sort of direct descendant of, of introducing SCA into our workflows, uh, you know, had drop an SBO monitor that sbo, uh, in perpetuity for every release, uh, in order to have there. But again, I think in other places, the serological assumption is that s om is, is ubiquitous to SCA AI can just, you know, grab one, generate one, and then, and that'll be good.

It's just a snapshot of time in, in fact, s om and s om is quite a living thing that, uh, now increasingly it's gonna have legal consequences if, if you don't manage it, right? Yeah. I mean, for the most part today, without SEA, you can't create an accurate SBO m because it's, it's not just a case of pull together all the SBOs of my dependencies, add them all together and ship it.

Part of the problem is most of those don't exist yet. So you don't have, you don't have the building blocks, you have to do the analysis yourself. You know, over time, um, I think it will morph more into SCA is able to validate and augment SBOs, but right now it's really the way to produce the start of an SBO that gets shipped down downstream anyway.

Right? So the fact that, um, we're seeing so many people have to lean on SBOs kind of, kind of goes back to my first point that there's still still not enough people are able to do it, because if they don't know what's inside their software, um, they're probably not doing any of these things at all anyway. Yeah, Absolutely.

And I, I think what's really interesting about that, uh, as well is that, um, is that, um, they're often being driven by very different personas, uh, even though they are actually very related. All these free topics that we've kind of touched upon so far are very related. There's actually a fourth element to this, which is license analysis.

Um, so many people do SCA just with a, just with a sort of security perspective. Hey, I wanna make sure that the software that I build is devoid of no more, the most critical security. One of this is usually the version that you see.

Um, but you know, an interesting thing over here in Europe is, 'cause we have pretty strong copyright laws in some of the countries. Uh, we've always had a bit of an aversion to misusing licenses. So some of the SCA work that, you know, traditionally start here was all about license analysis.

0 license thing or a feral GPL license thing. Um, but increasingly we're actually seeing a lot of risk, especially with repackaged, uh, LLMs, especially something like laa that doesn't actually have an open source license. It has a no commercial usage license, uh, on it.

You know, when somebody repackage like fine tunes it, repackages it and publishes it with a different license, you may feel like you're actually, um, actually, um, you know, free of any, uh, licensing terms. 'cause it, that retrained model came out with an MIT license. But underlying it, you're actually also covered by the original terms of service, which might or might not come, come back and bite you.

So what I mean to say about all of this, you know, talking about this licensing element is they're often driven by very different personas. You know, SCA came from DevOps wanting to do more DevSecOps, uh, malware analysis really truly came from a sort of security perspective. Hey, there's this new attack vector that targets developers.

How do we, how do we deal with that? S om is a compliance thing. It's a, again, a completely different persona that, uh, has to address in completely different things.

Um, and one of the sort of big challenges is, uh, or big inefficiencies, I feel like we're gonna see, you know, uh, this sort of, uh, next few years is people are gonna try and invent each and every one of those separately when in fact, to me, they're just facets of the one and the same problem. Yeah. Yeah.

I mean, I think when you think about going beyond, you know, just the SEA, the produ production of the inventory, you know, we, we, if you think about it as a part of a, a supply chain in the system, you need to be able to monitor those things for changes as well, right? And the, the analogy I use a lot is, you know, we all have cars and we're used to recalls and things like that, right? And imagine if the manufacturers never had to do a recall as long as they printed out the list of parts and put it in the glove box when they sold The car.

Funny enough, I literally go there today that my car is under a recall. So yeah, I feel that, right? Right.

But, but it, it absent that continuous monitoring of that bill of materials, it would put it on you as the end user consumer to I know it, to basically do it yourself and how would you know what to look for, right? And so that's kind of the modern equivalent of the sbo m is just the start. The SCA producing the SBO m is just the start.

You have to be able to take that and use it for infor important information. A, to be able to, uh, follow up, see when things, uh, when bad things happen to these components. You know, it's not that the component changed.

You're not monitoring that the SBO changed, you're monitoring that the state of understanding around the po the components changed, right? When, when cars are shipped, hopefully they don't know that the airbags are gonna be faulty, but later mistakes happen, they figure it out. And, and so the information about that change, even though the part didn't generating the alert, the, the equivalent needs to happen on, on the software, right?

Yeah. Uh, for sure. And I think, I think that's, that's sort of, I think why, uh, why, um, you know, reducing the supply chain problem into just, hey, you know, do some scanning during build time is sort of right, sort of a very natural reaction.

That's sort of the minimal possible thing that we're all used to doing. Now it's say, you know, I've got a scanner of, it'll compare my list of things to other things. But in fact, this sort of, the domain of the issue is, is far wider and leads to that logical conclusion of I'm selling out a product and that product may or may not have quality defects, and I need to be able to execute fixes.

Now, historically, you know, it's, I think, you know, we, we spend an entire episode talking about, you know, the regulation. But, you know, one of the big changes, the CRA and the PLD are gonna lead to a place where if you don't do stuff like that, there are gonna be fines and, uh, sanctions that can be imposed as a, as a result of not following us or best practice. So in, in that sort of vein of continuing on our predictions, uh, from our, uh, last time, um, I, it's actually, uh, it's actually not just, uh, not just, uh, a consideration that some of us have to do.

I think it, it'll be, it'll be sort of something that we're all forced to really think hard and true about. But the good news is that foundational element of SCA certainly sets you up for a starting point. So, agreed.

Um, and you know, funnily enough, uh, funnily enough, you know, if you think about, uh, think about, um, uh, all of these things, um, all of these things just in general, you know, there's been, uh, actually a couple of, uh, couple of sort of supply chain incidents, uh, quite recently that we've seen, uh, where, um, you know, I think there was a, there was a JavaScript, uh, component that actually got taken over by malicious actors. There's also, uh, uh, something called web free js fairly recently, a very popular, uh, JavaScript library used in crypto and, uh, sort of, uh, web free, uh, type activities. And that actually got compromised, uh, periodically or temporarily.

And I think that's a very good example of a type of supply chain attack that's now being executed. You know, I, I saw on Hacker News and, and a bunch of other places, and, you know, our research team kind of picked up on it, uh, relatively quickly. But that, um, I think is a good example where, you know, having protection at the network or ingress level is really actually the only way to avoid the type of attack that it tries to execute, because it really tries to execute on the developer machine using developer tooling rather than poisoning your software and then carrying, uh, itself, although that too can be a risk.

Um, and so having NASA a more holistic approach of, Hey, look, you need something to filter things coming in. You need something to filter things as they're being built to minimize, uh, sort of the technical debts that you're accruing, and then you need something to work out for it once it's out the door. Um, I think it's pretty important.

I, Yeah, I mean, we're gonna, we're gonna continue to see new and novel attacks on these types of components, whether they're fake components, the type of squatting we've talked about before, whether it's account takeovers, like we've seen, um, just this week there was another one, uh, what within Python, where, where the pipeline itself was actually compromised in publishing some malicious components, right? So it's kind of all over the map, and that's why you have to have these defenses in place to be able to deal with it. Indeed.

And, you know, just to, um, uh, just to, uh, plug a little bit of something that we, uh, did this week as well as we released new reports, uh, that dives into some of the malware, uh, publication patterns that we are observing and, you know, sort of surprising, not so surprised, uh, I'll spoil you, uh, one of the findings in there. There's a lot of it in NPM, in fact, MPM accounts for, uh, a huge, a huge amount, and there are a myriad of reasons mm-hmm. Why that is, mostly because it's very popular, you know, by itself.

Um, but regardless, uh, regardless, it just shows that that sort of risk landscape is following wherever. You know, we have popular, uh, development happening, you know, NBM and Python as an example. Uh, you know, they are constant targets for this type of activity.

Well, hey, uh, Brian, we're kind of coming up on time. So I guess it wasn't that controversial at all. Uh, you know, I think we, uh, uh, we have managed to cover, uh, quite a lot of it.

So, um, I would say, uh, I would say that, um, if you're fancy, have a read, uh, if you need something for your festive table, you know, perhaps under the tree or stocking filler, print out our report, uh, at a read and, uh, you know, see what that does for you. But, um, you know, I guess the takeaway for me today is, as I've been doing most of the talking here, uh, is, um, uh, I don't think the SEA is, is the answer. It's a part of an answer, but you need to think a little bit bigger.

Yeah, for sure. You need to be protecting, you need to be thinking about what happens after you produce the inventory. You know, how do you defend your developers against, uh, these other types of attacks?

Right. It, it, it, there, there's challenges that go in both directions. Further to the left, further to the right in your, in your pipeline and your, your, uh, A DLP.

Indeed. Well, with us, uh, Brian, thanks so much, uh, again, uh, for a, uh, lovely discussion today. And to everybody listening, uh, thank you very much indeed, uh, for sticking with us.

Enjoy your festive period. 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.

This is Textron tv. Hello and welcome to the Textron ITSM video series. I'm your host, Mike Ard.

Today we're with Julian Nieve, who's CTO for astronomer, and we're talking about, well, the need to modernize or perhaps revolutionize data ops altogether. Julian, welcome to share. Thanks Mike.

It's great to be here Is a conversation that kind of perplexes a lot of people. 'cause they'll say, well, we've been managing data forever and we've been processing data for as long as anybody can think about. It's core to everything we do in it.

What is it now about data ops that's changing the way we need to think about the way we process, manage, and work with data in general? Yeah, I think it's really about the level of operational maturity that folks need to get to today. You're absolutely right that, you know, the industry's been working with data forever in, in some shape or form, but I'd say the level of criticality on that data is only increasing over time.

And it certainly feels like we're hitting an inflection point today where, you know, businesses are starting to rely more and more on data as a source of competitive differentiation, right? They collect all this data, they put it in a data warehouse or a data lake, and they start to look for ways to get value out of that data, right? Whether it's surfacing that data back in a product or using it to make more intelligent decisions, um, or even, you know, training LLMs or, or AI models in the kind of most extreme cases today.

Um, and that's kind of put data teams at the, really the center of, of the map, um, because they are, you know, the, they hold the keys to the kingdom, right? For, for lack of better words in terms of how you access data. And that's a pretty big shift from I'd say the last decade or so where, you know, the software teams have been kind of the, the core of everything.

Um, and you know, if you look at what's happened in the field of software, there's this whole field of DevOps. It's kinda been created and innovated on over, you know, the last decade or two. It's really around taking the work that these software teams are doing and make them more productive, make it easier to maintain existing systems so they can focus on building out new use cases.

Um, and we're starting to see a lot of that now with, you know, the world of data where data teams today are bogged down by, um, kind of the operational overhead of maintaining all of their existing data assets and data products. So they don't have as much time, um, to build out, you know, new use cases and, and new ways of finding value. To your point, DevOps is kind of a philosophy as much as it is anything else?

Is data ops essentially also a philosophy or are there multiple ways to go about data ops? I mean, what's the coer? Yeah, absolutely.

I think, you know, there are very, very similar par parallels to, to the world of DevOps where, um, it is certainly more of a philosophy than I'd say, you know, a set of tools, although there's a bunch of tooling out there that can help you, um, with it. Um, you know, I'd say companies traditionally have had to, um, you know, treat their data teams almost as a service center, right? You go to the data team and when you have an interesting question that needs to be answered by data, um, and, you know, then the data team ends up, um, you know, dealing with these kind of ad hoc requests all day long.

Um, I think that, you know, the shift to data ops is really about treating your data team more like a software team, where there will certainly be, you know, ad hoc things that come up now and again, um, but really, you know, taking the work that they're doing, um, giving them the context of kind of where the business is going and where the company's priorities are, um, and letting them build, you know, interesting kind of data products and, um, analyses to, to help support the business. So it, you know, it is certainly more of kind of a mind shift, mind set shift to start treating data teams more like software teams. Um, and there's absolutely tooling that, that can help with that.

So I think it's, you know, it's a little bit of both. I feel like the, it's not just the volume of data that's increasing, but the velocity at which it is being processed is fundamentally changing, and that requires maybe this different mindset that you're describing because, um, we have to make sure the right data is in the right place at the right time, much more these days than we did when everything was kind of more of a batch oriented kinda processing. And if it happened overnight and it worked great, but, um, is, you know, so has the whole mission requires now, you know, somebody who really is a data engineer.

I think you're absolutely right. I'd also add that not only the data, does the data need to be there at the right time, um, but it also needs to be of high quality, which is oftentimes what, you know, these data teams struggle with the most, you know, these, these data teams have to work with, you know, external systems, like different marketing tools and, and CRMs where there's a lot of manually inputted data in that, you know, data can be, um, misshaped or, you know, ha have certain anomalies part of the time. And so, you know, as a data team, if you're having to both like fight, um, against the tools that you're working with to make sure that, you know, they're always, um, you know, working and you know, they're delivering data in the, the way that you expect them to, um, and you have to go continue building out new use cases and delivering new value, um, you know, it's almost an impossible task, right?

Like our, our data team wakes up in the morning and, you know, they look at all of their pipelines, they look at kind of all of the data that was supposed to have been delivered. And you know, more often than not, there's some small problem with the data. So they have to go spend time looking into it, fixing it, rerunning pipelines, um, and, you know, uh, trying to both maintain kinda the existing use cases and tables and dashboards and, um, data products that, that our team has built and look for ways to, to deliver new values is really tricky.

And, you know, I think we're seeing this also a lot kind of in the, the world of AI where a lot of companies are, you know, putting the cart before the horse, so to speak, right? Everyone wants a very strong AI strategy, they're looking at the companies around them, they're looking at VC investments, and it's pretty clear that you can get value from ai, right? I'd say in the first year or so since, um, chat GPT was announced, um, building differentiation in the space of AI really was about how quickly you could go take these off the shelf models, put them in your product, and as long as you could do that quicker than your competitors, that's now a reason for, for customers to come to your product over others.

Um, I'd say gone are those days though, right? Everyone has, has figured out some way to take an off the shelf LLM and I use it in their product to build differentiation or used it to make their, their business more efficient. Now, that differentiation has to come from how you take these off the shelf models, whether they're open source models or commercial models, and supplement them with data that you have unique access to.

Um, and so that puts, again, the focus right back on these data teams who are now having to maintain these, you know, existing data products and start to be pulled into the world of ai. Um, and, you know, I'd say in the, in the net, it's great for these data teams kind of be at the center of everything. It means that, um, there's a lot more investment being made in, in data teams and data infrastructure across a, a wide variety of organizations.

But unless they have the right kind of mindset, the right tooling, um, and the right processes, it becomes very, very messy very quickly. Well, so is it, I'm gonna force this issue. I mean, to your point about the cart before the horse, eventually we, we will figure out to turn the cart around.

So do you think that in a lot of ways this whole rise of AI is pulling the state ops conversation along and maybe it's just long overdue? Yeah, I mean, I think absolutely it is, right? Like there's, there's now an increased level of, um, scrutiny and understanding of what data teams are doing, right?

When you start to rely on data teams, both as a source of kind of using data to build a data-driven business, but now, um, to also supply these AI models and LLMs with, um, data becomes a very, very core part of your business. Um, and you know, I think if you look back five or 10 years, um, data teams, you know, have, have always been around, I'd say the use cases at the time though, were more around, um, supplying internal dashboards and analytics and reporting. Um, and that's certainly helpful.

Um, you know, it helps you make data-driven decisions. It helps you understand kind of the, the business and the markets. Um, but if you fail to do your job as a, as a data team, you know, 10 years ago you have maybe some angry exec somewhere that, you know, is frustrated that their dashboard isn't updated.

Um, if a data team can't properly deliver data reliably today, um, that business loses a source of, of competitive differentiation. Um, you know, they, they lose the ability to make data-driven decisions. Um, if they're not supplying data to, you know, these AI models in a timely manner, um, these models will become out of date and, you know, they'll give, um, potentially inaccurate answers.

And trust is such a core problem with, um, LLMs and, you know, kind of generative AI more generally because, um, of how non-deterministic they are, right? Like, if I go start using an LLM or an AI tool and it gives me a bad answer once, uh, my level of trust in that system decreases very, very quickly. Um, so I think certainly the, the kind of rise of AI has put data teams back at the, the center.

Um, and that means that, you know, data teams now have to go adopt, um, whether they call it a data ops mindset or not, um, you know, they need to treat themselves more like software teams who are responsible for not only delivering a set of, you know, kind of products and use cases today, but also can do so in a way that they can continue building new things instead of spending all day maintaining the existing things. We talk a lot about how data is core to building the AI models, but, uh, will we apply AI to DataOps itself and will that become somebody that we or maybe are able to manage all this data at scale? Yeah, I'd say for the, for the teams that can do it well, it's gonna be very, very instrumental, but in some senses it's a, it's a double-edged sword, right?

I think if you are a data engineer or data scientist or data analyst who is very intimately familiar with kind of your, your data platform, um, and you can use AI to your advantage, it's gonna make you more productive, it's gonna make you more efficient, um, and it's gonna kind of decrease the, the burden of the existing use cases with things like, um, AI assisted troubleshooting or, or pipeline offering. On the flip side, though, AI lowers the barrier for other folks to contribute to the data platform right now, an executive somewhere, or, you know, someone from the, the marketing team as an example, can go, right? Um, can go to chat GBT and ask it to generate a SQL query, um, to go analyze some data from the data platform.

Um, and that's, that's a good thing because it means that I think there will be increased participation and engagement in these data platforms. But when you start to do that at scale, right? If everyone from the marketing team and the sales team and, um, other teams start, you know, writing a bunch of pipelines and running a bunch of queries against your data platform, if you're not able to kind of control that at scale or help those folks interpret results or maybe understand nuances in data, you're gonna end up in, um, a, a, a world of hurt, right?

Because you're gonna have a bunch of pipelines that, um, less technical folks have, have contributed that maybe don't really understand how, how the data platform works. So I think if you use it in the right way, um, and you use it as kind of a way to go make the existing data teams more productive, I think it's gonna be a huge unlock, and I think it can help lower the barrier for other folks to contribute to and interact with data platforms. But you have to be careful on, on that side of things.

We, you know, you hear the phrase all the time, right? Data's the new oil. And I think, uh, the problem is, is we don't really know how to refine it, and as a result, we just kinda board it, and we have lots and lots of data everywhere, but we're not getting a whole lot of value out of it, and storage costs are adding up.

So is there a sense of frustration in the system right now that needs to be dealt with and maybe data ops is the answer? Yeah, it's, it's a great question. Um, I, I think definitely, you know, data ops and also kinda the advent of, of AI can help you get a lot more value out of your data.

Um, I'd say the, you know, the other trend that I've noticed going on is, um, data teams can now kind of collect and centralize data at massive scale today, right? You have a bunch of technology out there that can help you with that sort of thing. And, you know, once you get all this data in one place, the question becomes like, what do you do with it?

Right? It's, it's not as simple as just let me go build a dashboard on top of my entire data platform to, to help me understand. Um, and that's where honestly, I think businesses have a, a great opportunity to use that data to their advantage.

The two examples that I like to go back to are Netflix and Spotify. So, you know, they were both quoted in, uh, Andreessen Horowitz's original posts around software is eating the world because, you know, Netflix and Spotify were able to take these, you know, very traditional brick and mortar, um, industries and, and music and entertainment, um, and disrupts the entire thing, right? By building, um, software that really lowered the barrier to accessing music or accessing TV shows.

Um, and, you know, that's been incredible to see it kind of put them at, at the forefront of that. But if you look at how they maintain their differentiation today, how they maintain that position, it's really through their use of data, right? There are other platforms now that give you the same experience, the same access to music and, and entertainment as Netflix and Spotify do.

But, you know, because Netflix and Spotify have so many users, they can build, um, these great kind of data models and personalization models and recommendation engines, um, that keep you super, super engaged. Um, and I think, you know, they to me, represent very canonical examples of like, companies that have been able to make this transition from, you know, building software as a source of differentiation to, um, you know, of course you still have software, but you now also lean into type of data that you as an organization have unique access to, um, to build, you know, stronger retention, user acquisition engagement on the platform. Uh, so I, you know, I think you're absolutely right that just getting the data in one place is, is not enough.

You have to go figure out clever ways to use it as a way to, you know, drive your business forwards. So who's in charge of all this? A while back we saw people talking about chief data officers, and now we hear about chief AI officers and there was digital CXOs, and now the CIO is kind of stepping back up and saying, Hey, you know, it's all about the data, so I'm in charge, but what are you seeing?

Yeah, you know, I think there's really two ways to look at it. I'd say there's a very tops down motion of executives now care more than ever before, how they're able to, you know, collect, understand, and use data at massive scale to go drive their business forward. I do think AI has helped a lot with that conversation because it's, um, kind of forcing people to understand that before you can go build an AI strategy, you need a, a data strategy.

And, you know, for better or worse, um, AI is, is on the top of mind of, you know, every kind of boardroom and, and executive room out there. Um, and so that's increasing kind of the investments and the intention and, and data teams. And I say that happens across the executive team, right?

From the CEO who understands that you can go use data as a source of competitive differentiation, whether that's in traditional, traditional ways or, you know, using AI and ML to, you know, CTOs, CIOs, CDOs, um, basically see anything oh, at, at this point. Um, but there's also a super interesting kind of bottoms up motion that, you know, we're, we're seeing as well where, you know, data engineers, data scientists, um, and other kind of data teams, they're the ones that have a very intimate understanding of the data platform and the type of data that you have access to. Um, and they're able to go build a strong sense of intuition for how you can use that data.

Um, some of the most successful examples I've seen of companies adopting AI and ml, um, you know, in a very pragmatic and realistic manner has come from the data, right? I think a great example of this is, um, RAMP who, you know, uses air airflow. Um, you know, one of the products that we work on, um, you know, their data team has the full context of what their users do on the platform, what their support team is responsible for, the type of data they have access to, and they've been able to build an incredible suite of, you know, AI and ML products on top of that data that didn't come from some executives somewhere saying, Hey, we need to go do this.

It came from the intrinsic interest that, you know, these data teams have and, and where the market is going and where the technology is going. And so that's been really an, an incredible movement to see as well. All right, folks, I think we're all starting to finally realize that this whole AI thing is about the data.

I think the part that we forgot about was that it was always about the data. Hey, Julie, thanks for being on the show. Of course.

Thanks for having me, Mike. All Right. And thank you for all watching the latest episode of the Techstrong ITSM series.

You can find this episode and others on our website. We invite you to check them all out. Until then, we'll see you next time.

com, techstrong, ITSM, what, uh, text Strong AI Security Boulevard, text Strong tv, a whole bunch of Textron stuff. But I'm here today moderating a great panel for you all on Skill Up Day. We're, we're happy you're joining us this month.

Skill Up Day is a pretty, pretty cool one. It's dealing, of course, with DevOps and the relationship of DevOps and I and how to be successful with it. I've got a fantastic panel of folks that I want to introduce you to who's gonna discuss this topic with me, and let me introduce them to you.

I'm gonna start from, well, on my screen, he, he's on the bottom. I'm gonna go from the bottom up. He's someone I've had the pleasure of knowing, I don't know, 12 plus years through a variety of different roles.

Uh, one of the smartest people I knew on in C-I-H-C-D for a long time, my friend Eric Minnick. Hey, Eric, if you wouldn't mind introducing yourself. Hey, thanks, Alan.

Uh, yeah, as you're saying, I've been in the DevOps space for a long time, uh, previously with Urban Code and IBM, and now I'm really enjoying life as a director of DevOps solutions at Harness. Uh, co-author of application release and Deployment for Dummies. And very excited to be here with you today.

Thank you. Thank you, Eric. It's great to have you on.

Uh, next up I want to introduce you to Paul Davis. Paul, I'm gonna let you kind of fill the audience in on your background. So, hi.

Yeah, my name's Paul Davis. I am Jay Frog Steel ciso, and you might be saying CISO DevOps idol y. Well, uh, I had the honor of, uh, being exposed to ILE many, many years ago, and it's really 'cause security people are process Wes.

We like consistency, and we also like to have a common vernacular, and ILE works well on that and making sure we have a common language to talk through. And it's evolution over the past few years has been fairly amazing as it's modernized itself to reflect the sort of dev development world. So, um, I'm happy to be here and looking forward to the conversation, so thank you.

Well, I'm looking forward to hearing your views on this. Um, I've, I've got some questions for you, but first I need to introduce our last, but certainly not least panel member today. It's my friend, hope Lynch.

Hope. Why don't you tell folks a little about yourself? Certainly.

Thank you, Alan. Uh, hope Lynch, senior director of platform at CloudBees, uh, started my career in it, so very familiar with it tell, and the importance that it ascribed to it, uh, transitioned, uh, over time towards more engineering strategy work. Um, but definitely, uh, see the, the intersection there.

Uh, spent time at Cisco, spent time at Red Hat, now here at Cloud Beats, and enjoying. Thank you. Welcome.

Thanks for being here. Hope so. Let, let's kick right into it, guys and gals.

com, uh, 10, 11 years ago, Eric, as he mentioned, was an urban code and idol and, and, and, uh, DevOps were not exactly peanut butter and chocolate. Paul, I think you hit on one of the main reasons right off the bat, which is I is all about standardization, all about sort of, uh, you know, launching in lockstep and following very specific, uh, protocols and policies and processes. DevOps, when it first came on the scene, as, you know, the new kid on the block, you know, refused to be defined it well.

There was no manifesto, there was no best practices. There was. They, they actually relished in that they kind of, in many ways flew from the seat of their pants reacting and iterating based upon feedback loops.

And, and so a lot of the early DevOps people just looked at idle as everything that was wrong with it and developed it. And what DevOps was set out to fix the idol folks, as you said, Paul relish the idea of, of of, of knowing what comes next, of knowing what, you know, following a process. Everyone's on board, everyone knows what's, you know, what's going on.

And it just, it just seemed, you know, that they were banging ads and they didn't seem away for these two frameworks to work together. Um, what changed, Paul, I'm gonna let you kick it off. You, you mentioned it in your opening remarks.

What do you think has changed that? Or maybe it hasn't changed? What do you think?

Oh, It has changed. Um, development's moving a lot faster now. You know, we are agile as you meet the manifesto and all that sort of stuff.

You talked about that. But the other thing is, is that software is coming far more dependent on the IT infrastructure. And so the speed that we need to move at and speed we need to deploy means that we have to have a way of communicating across the teams to say, this is what I need to do, this needs to get in production, this needs to happen, et cetera.

And so that whole thing is sort of driving us through. And now when I'm gonna put my dev hat on with the regulations, wanting consistent secure software supply chains mm-hmm. Those two, it's almost like they were developed in two separate parts of the world, but they all have the same vision.

It's the whole, the same steps there. We might have different terminology for the stages, but in the end, what everybody wants to see, whether you are a customer or a software company or you are delivering software, you're a business, is that consistent process from beginning to end. And that's what I love about sort of version four is it does pivot that cross and create that connection.

So for me, I think it's a sort of a, hey, we are actually talking about the same thing. We, we might wanna use different words, but we have the same goals. And I think that's a big thing there that we want to drive through.

Oh, Eric, Yeah, I, uh, I agree and I think there's some factors, um, other factors driving this convergence as well, right? So everyone talks about digital transformation, that is, that is a big job and DevOps teams are engaged there, but those transformations are often led and managed by it. Um, that structured approach that ITIL can bring can be a great compliment to the way, uh, DevOps looking at more rapid, uh, iterative cycles as, as you had mentioned.

So aligning those two. Um, looking at how incident and problem management, uh, works with the CICD pipelines, how change and release can work, uh, with automated deployments. Um, how we can use IEC for configuration management.

There are a lot of ways these things can go together. Uh, not that it's easy, um, but, but it is complimentary. Yeah, I, I agree.

And I, it may be a happy accident, uh, but I, I think ITIL has for a long time had the structure in it to support a DevOps approach. And that if you have a standard change, uh, hopefully I'm, I'm getting standard to normal, right? But if, if you have a standard change, right?

That's something that's low risk, there's a defined procedure for it, and because it is low risk and standard, you don't need to go through a cap. You can just do it, right? And what has DevOps been trying to do this whole time is make software delivery a well-defined process.

It's the pipeline, right? You push a button or you just commit code, it happens. You have a standard process and through all of the testing, through all of the security scans, through all the safety nets you have watching production, you're driving down risk, right?

The risk that it's gonna fail the blast radius when it does fail. And so you drive down the risk, you have standard procedure, now you're a normal change. You don't have to go to the cap.

And so where I think we instinctively looked at this and said, oh, those ITIL guys want us to go to the cab anytime we do a deployment. Uh, so that's incompatible with DevOps. No, the, the gate was always there.

The bar was always there. Make it low enough risk. You don't have to go to the cab now socially, did that always work?

No, but I think we're getting there socially now. Yeah. So to me there was a little bit of, you know, Muhammad coming to the mountain, but the mountain came to Muhammad a little too.

Yeah, right. I, I think Paul, you mentioned ILE four now ILE four is no longer new ILE fours min now probably three, four years now, right? But it was a watershed moment for IO and, and it's wrap approachment or reproachment with DevOps and Agile and these kinds of, you know, frameworks.

I think it really was a game changer. It it's, it was a little bit, if you can't beat 'em, join them type of, of a moment. But at the same time, I think DevOps matured a little bit.

It wasn't just, it was no longer the wise kid, wise ass kid hanging out in the school yard. DevOps teams realize it's a big world out there in the IT real, and they need to work with everyone. They can't afford to alienate teams of people like this, right?

And, and that DevOps in and of itself in a vacuum would not be successful. They needed to work with the ops teams and with the ITSM folks. And, and we see it even now with platform engineering, SRE, all of these folks.

It, it literally, as someone once wrote, it takes a village to develop and deploy and manage software to manage it. And, you know, I think that DevOps world has, has recognized that most of us and and so no longer looks at EO as some, you know, archaic dinosaur or something that we're here to replace. We're not here to replace them.

Um, you know, so it, it was, you know, both sides of, of it coming together. I now hope I, I'll give it to you with CloudBees, right? Yeah.

You guys have a, a ton of Jenkins users have in the past of, of legacy. Um, do you guy, have you seen that? I mean, is that accurate to what you would see it at CloudBees, you think?

Yes. Um, and like you've said, um, as before, it's no longer new, but some people who don't know about the changes in itil, right, are still thinking about the heavy process oriented framework or, you know, that service lifecycle model versus the look to something that is more adaptive and more value driven. And one of the areas that does show up is having conversations with customers, um, about value stream management, right?

Once you start talking about the value stream, those, those processes come in, those connections with the development teams come in and even if they aren't using the words itil, right? You, you have to use some of those processes if you, if you want to smooth your path. So, so we do see that, we do hear it when we're talking to customers.

And though some of them may not realize it, they are, they are on that road to convergence Fair. Paul, Eric, thoughts on that? I, I think the, the, so I, I have the glamorous, uh, journey of dealing with ile, the first version.

Um, at that time I was running a global security program and they said, Hey Paul, we are moving the whole organization to ILE and you need security to move to ile. And I went, okay. And it ended up running two iterations of ile.

One where I talked to the rest of the world and then one for the infrastructure that my security team was running, right? Um, and I bring, and I, when I look at the, the sort of the iterations of ILE over time, I still feel that there is a gap and I'm kind of conflicted 'cause I don't wanna corrupt ILE for what it's doing, but I think there needs some mapping to be done between you, you know, you scared me when you said get cabs. That really scared me.

Um, I must admit, I, I, I big changes security paranoia, but from the perspective of like getting the security gates in place at the right points, automating it and stuff like that, and aligning that with, um, you know, the idle framework and things like that, I think is important. Um, but it's almost like the, the, I, I don't wanna say this, but there needs to be another iteration, or maybe I'm biased 'cause I'm a security person, but I, I feel that there needs to be some synergy. I mean, 'cause problem and incident, the number of times I've had to explain this is an instant.

Now it's become a problem is like, okay, yeah, incident's over really, but tidy up well, how the incident lasted a week, but the tidy up takes six months. So probably that peak. So that kind of thing.

What worries me, um, from that perspective, um, and I think that, I dunno what the others think about this idea of alignment vocabulary is so harsh. I incident problem, I was tripping over standard and normal, um, you know, deploy and release. Uh, you know, we, we have synonyms that mean very different things all over the place.

Um, so I, I don't know if additional iterations fix that or if, if that's just the challenge of, uh, having a lot of similar ideas in our world and maybe we can't use individual words to describe things. Speaking of that, I think one way to get over this hump, um, you know, me, sometimes I'm an optimist. Sometimes I tell Alan I have a controversial opinion.

This may be one. But, um, instead words numbers, right? So there are KPIs that could be meaningful, um, across, right.

There could be a dashboard where it is, how long does it take us to recover that will be meaningful to the idle team that will be meaning to full, uh, to the DevOps team. Uh, something that, you know, hopefully is customer centric metrics, um, that can give some realtime monitoring, some long-term trends. And I think that helps you to a degree get over some of the issues with language and just have the numbers and the trends that the teams can look at that they are both, uh, impacted.

Yeah. And and the more customer centric, the more business-centric those numbers are. Yes.

The easier it is to get everyone on the same side, right? Yes. You know, we wanna be making more money, we gotta deliver some innovation.

Um, we're not gonna be successful. We're not gonna serve our customers if the site is slow or down or leaking their information. Um, but those sorts of very clear business aligned measurements get people on the same side.

And that helps. But it's kind of funny that you, we, I mean, business KPI is really important because it, it's, it's like the translation layer between what we do mm-hmm. And what the business understands we do.

And there are huge disconnects in that space. It's just horrible to think about. But the thing for me is, is we need talk to the developers, the feeder of this content to DevOps.

They don't think about uptime availability, you know, continuous improvement. They're told, Hey, write this application and get it out quickly. And their metrics don't always roll through.

So I sometimes worry that ILE doesn't translate all the way down the chain. You know what I mean? Sure, True, true.

Go ahead. Hope. I'm sorry, did I didn't.

Oh, That's okay. And, and I think, um, you know, there are levels, uh, in DevOps as there are across the organization, right? So maybe you ask someone who's the manager of the team who owns translating that into something that is meaningful goals and OKRs for the team to hit.

They may never look, look up the ladder as far, um, to understand a lot of those business metrics. But some of these things should be reflected in, in some of the OKRs and other things. I think, uh, that the team's trying Agreed.

Go ahead. How I was gonna say, how about this for an OKR? Um, do you know 25% of a developer's time is spent fixing bugs and vulnerabilities?

Yes. Yep. Yep.

And, And here's the horrible thing is the executives are suddenly realizing, Hey, we've got this, this impacts our availability. 'cause it's a risk, not availability, not the system's running. We have less change windows 'cause we don't have to keep upgrading and patching things all over the place.

That'll be really nice sort of thing. Um, so the, the whole thing of sort of the, the metrics, um, I think it's a key thing. I know CISOs we're stressing a lot now 'cause we have to think about supply chains and software, and we have to now start, start talking to new teams about this stuff.

But it, it worries me that, that those metrics, those KPIs, um, they have to translate. And I'm, I'm counseling a number of CISOs now on stop talking about vulnerabilities and talk about business impact. And this does have me thinking maybe I need to be brainwashing them with idle.

Yes. Sounds like a good plan to take over the world. But, but you know, seriously, let me interject there a sec.

I think when I, I mentioned some of the things that were driving ITIL and DevOps to come closer together. We, I i I omitted security and, and Paul, you reminded me, right? When you have today Jfr, for instance, right?

The emphasis on DevSecOps and security and compliance, it's the same for CloudBees, it's the same for harness. In fact, it's the same for every DevOps company. GitLab, GitHub, you know, name a DevOps company.

They call themselves DevSecOps companies. Yep. Right?

And, and quite frankly, security and it's, and, and how it interacts at an ILE organization. Idle has become a friend in many ways to the security team. So this is another sort of gravity, well, if you will, that are pulling these two planets, you know, orbit's closer together and, and, and making sense why we need to work together, why we need to work together in there and, and we shouldn't, you know, I I think we have to acknowledge the role that security plays across the entire tire factory, if you will.

So I, I, I hate the factory analogy, but, um, but, but I, I I would say that very, very short term, you can be sloppy and bad and fast, but the only way over long term to be fast and still be in business is to drive exceptionally high quality. And that's testing and it's all your security stuff, right? Those things go together.

They're hand in hand, um, at least conceptually, right? Security problems are bugs. Um, performance issues are bugs.

All of these are bugs. And to drive that quality is what allows you to have rapid change. It's what gets trust in what you are doing.

That's the gate is quality and security is arguably the most important part of that right now. Agreed. You, you've all fallen into the trap.

Remember I said we need to align idle with, with security. You, you have brainwashed you all, you see reverse logic. I said teach the CISOs, I still you.

They'll say, yeah, but, but you, you're right. I, I mean, the thing for it is really we are, we have this terrible thing called the triad, which is the confidentiality, integrity and availability. And it's a curse because it means, um, we can't say no to protecting the organization.

And, and DevOps is part of that journey, you know? Agreed. That is.

I, um, guys, we have less than 10 minutes left. I, I, I left this topic to the end. I, I hope it doesn't run away with us, but I, I wanted to, you gotta mention ai, right?

Because everything's AI today and, and the role it's playing, whether real or not, it, it certainly is sucking a lot of oxygen in the room. Where, where do you see AI playing in this relation, this budding love affair, if you will, of DevOps and IT and security? Where is it today and where do you think it might be in the near term future?

Who, who would like to take first crack at that one? We're all jumping in. Okay.

Sorry. Go for it. Hold on.

Come on, come On. I was gonna say that, um, when, when we bring in ai, if we talk about the, the one that, that comes to mind for everyone and they think about generative ai, and if we also think back to what you were saying about quality, right? Uh, there is an opportunity to relieve one of the biggest pain points when I was in it.

If there's an incident, getting good documentation, getting timely documentation, getting all the information, what an opportunity to use AI to assist with that documentation, perhaps through some observability tools, perhaps through, um, you know, conversations that have been attracting Slack, et cetera, right? And bringing that information together. So now you have someone who needs to review.

It's been documented and hopefully, um, it's easy to search even if it's documented in the past, I have had to search through, uh, confluence documents other things to find a past incident to reference, right? For a current incident. Um, the, the slowness and the amount of time that takes, I, I think if I were still doing that work now, I would be chomping at the bit, uh, for the changes, uh, that AI can help with.

I, I was talking to the, our director, VP of, uh, cloud engineering yesterday and he was talking, when we have incidents, we're using AI to yes. Find those past issues to get remediation. I like that's, that's today.

Yes. Um, and I mean AI's everywhere and it, gen AI is a little new, but other aspects have been around for a while. Like in the testing tools, um, the screen scrappers have been AI powered for a long time to automate building out tests.

Uh, monitoring side has been rich in machine learning and AI for a long time. It helps you reduce the risk of a deployment, right? You know, that you're doing a deployment, you apply some machine learning across your observability suites, you go, oh, doesn't look good.

You roll it back before things are on fire, right? Helping detect smoke before fire. Mm-hmm.

Um, but I think a lot of these things have been fairly optional for a long time. But as developers are becoming more productive using tools like copilot mm-hmm. Everything downstream needs to be so much better, so much crisper to keep up with an increased base of innovation.

Um, AI is widespread now. It's gonna be everywhere and it's gonna be critical as we go forward Slowing, I'm gonna be slightly controversial. Okay, good.

Go ahead. Okay. So AI is in its early stages.

Um, first of all, please do not use chat GPT to generate your incident report. Okay. True.

This is build your own Yeah. Career altering event if you do that without reading it and checking it. Okay.

Yes. So I, I, I work, you know, I've been working with AI for many years from as you talked about it. And I think, I think we need to like things like one of the most exciting things I heard recently is we could use it to generate documentation ho, which is like a lovely thing to do.

If any you could do the release notes, that would be brilliant as well. But I think that's pushing it a bit far. But the thing for me is when we look at ai, the great thing you can do, if you know how to do what I call socially engineering chat, GPT, is get it to tell you about exceptions.

Don't get it to create, but say, what am I missing? And if you learn how to use these AI agents, um, and you know how to put the guardrails in place and give it very clear instructions about what to do, then it can help you. This is another tool in our tool set and as we were discussing, I think it's like, Hey, I will solve everything.

No, but it will accelerate things, which means for DevOps teams, it's gonna get, there's gonna be more, more things to look at. More volume, more is, so automation is key. But I do like the, you know, as you talk, hope about the using it to find previous instant data, but also be very careful about who has access to that data.

'cause you can have PII in there and you gained a whole new game. Let's not even talk credit cards because, so you have to be very careful about what you expose to those in those data sets to control it. So treat it cautiously, don't trust it, but use it as another tool in your tool set.

'cause it's gonna make life life a lot easier. Mm-hmm. And that's really a key thing though, that last sentence, it's another tool in the tool set.

It's not, it's not Skynet, it's not magic, it's not, you know, any, it's a tool and tools, you know, tools make the person, um, I was thinking though, like Paul, you mentioned, and we all have seen the figures, right? Developers spend something like 11, 18% of their time, uh, fixing bugs, closing vulnerabilities, patching, if you will, or, you know, remediating vulnerabilities. That to me is the kind of stuff that we, we can maybe see AI take a better role going forward, right?

Because we're already using AI to find vulnerabilities. You right? And, and see if they're viable.

But can we not only find them, but fix them in one fell swoop and free up 10% more of a developer's time? What's 10% of a developer's time works, Right? I, yeah, I I I can believe the thing for me is, is it's all, like, everything everybody always talk about shift left and everything.

The, the quicker we can find the problem and solve the problem, the less work it causes further down the pipeline. And the key thing is, is enabling the developers to understand and give them tools that they can use properly to discover a bug, an issue or a problem or a weak, you know, they haven't cleaned their input. Another stat top in the top five, we still have buffer overflow, cross site scripting.

And it's not cleaning your inputing. I mean, it is just like secrets. I mean all these things, if we could get a level and say, hold on a second before you admit this, uh, you've got a bug here, you can fix this.

And, and we can, and using AI to do that passing and you know, looking in front of both of the point of view of the source code, the source code quality, but also the quality of the external libraries and open source components using is a key thing. If we can block it there, then we can show improve KPIs, da da da da, reduce the load on DevOps and make sure that we can handle the increased volume because there's more, there's software development's not slowing down, it's accelerating. And that means we've gotta find ways of dealing with it.

So yeah, so, So I'm thinking maybe you have found the great uni buyer, right? Between ITEL and, and DevOps. It, you know, developers don't want anything that's gonna increase their workload or they feel waste their time.

ITIL teams are, are trying to meet the demands for compliance and governance and oversight. Um, but if there are some AI magic, call it magic for now in the middle, right? That can alleviate the workload but uh, improve, uh, the traceability of some of those processes.

And yeah, I mean we, we have the code, we have the scanners that are telling us that there's a CDE here. Um, you know, the tooling is increasingly getting to the point where it'll put two and two together, use some LLM and say, look, it's this line of code. Let me explain the CVTE to you in plain English and a code change that's gonna resolve the CVE looks something like this, right?

Um, and whether we want it to actually just do the pull request, that That's A little more debatable, A little nervous there. But yeah, At minimum, um, I don't think we're very far from it being very to put in the full request. Yeah.

And the trick is gonna be just like on your incident report, just like if you're using chat GPT to do your homework or anything else, like you gotta read it and you gotta own that output at the end of the day and make that change, right? You can get off the blank page, you can get guidance on where to go with some generated code or whatever. Um, but at the end of the day, it's your name on the, the commit.

Uh, you're the one who proven it, you're the one on the hook for it. And we need people to do this just like, you know, we have autopilot, but we still have some humans in the cockpit for when things go wrong and to keep an eye on the autopilot. Alright, um, guys, unfortunately we're at our 30 minute time that we were supposed to go here or we're over that, but it's okay.

Uh, Paul Davis, JFR Hope, Lynch, CloudBees, Eric Minnick harness. Thank you all. Thank all three of you for joining me today on this panel.

I hope our audience found it interesting. Look, I will say that E and DevOps haven't become chocolate and peanut butter with a little security on top. So, and AI maybe, you know, maybe the, the missing secret ingredient as well.

I hope you've enjoyed this. Uh, there's plenty more today on our skill updates for DevOps and Idol. So please stick around for other sessions.

But until next time, this is a shimmel for Techstrong. Have a great day everyone. Hi everyone.

I'm so happy that you could join us today for this really cool topic. I'm very excited to talk about this as well. So gamification, gamification is something that probably a lot of you techies or computer geeks might know, but it's not necessarily something that we are putting into project management very often.

Um, the deal with that is projects always have constraints of time, money, we know the drill, anything extra, anything fancy usually gets left behind. But being an agile coach, I'm really passionate about gamification and I really think it will make your project go so much better, so much smoother, and also will really boost the motivation of people in your project. Um, as I'm dealing with a lot of like agile transformation projects and also like getting more agile techniques into organizations and doing that through pilot projects, I think it's really interesting to see what we do in such circumstances.

And then we can also map it to like more general projects. Like where can I use this? How can I use this?

How will it help me? And basically also give you a couple of pointers on how to sell it because you will have to ask for maybe extra time, extra funding for this. And I think it's really, really a cool thing that will merit the investment that you'll put into this.

So that said, let's get going. No time to play. Why you should use gamification in your adult projects.

So we are going to have, have a look specifically at how it can improve motivation. 'cause that's, I think, one of the biggest advantages that we have. Having a motivated project team will get just so much more work done and also get work done smarter, I think, and a lot of this is coming from the agile idea of having people collaborate, participate, being cross-functional.

Those are a lot of things that actually happen in projects already. So it's a beautiful mix. So what does that entail?

What do we do here? So the elements of gamification come from game design basically. Um, it's actually a pretty old concept.

So it started in, was coined I think around 2006. And it came from of course, game design, it like all of that things, all of those things. But it's very interesting to see how it has moved on since then.

So if we talk about gamification now we're talking more about like a, a rough concept. So it's a concept about making things look like games. And if you know the movie Mary Poppin, you will know what that means because, um, that is what she actually does with the children, right?

She comes in, she says, chores are no fun, let's make a game out of it. And you can get prizes when you do it right, and when your room is really clean, uh, you will get an enterprise and we'll all be happy and it will, will have been a lot of fun and we'll sing while we're doing it and so on. So that is like a good metaphor, what gamification actually is.

It is taking things that might not seem very attractive right now that seemed like a chore that very possibly you will be doing over and over again. And then taking an element of that and turning it into a game by giving you some sort of like rewards, um, making achievements and goals out of it, and then having fun while you do it. So why is this so powerful?

And the interesting thing is that it really taps into our human desire for competition, uh, in one way, like trying to be as good, as good as everybody else, or maybe even better. And it'll also help us see progress and achievement a lot better, which is basically what motivates us. Seeing progress and achievement will give us this sense of accomplishment.

And that is something that as human beings, we really need if we want to keep going. And in the projects where we have like little time and we have uh, a lot of stuff that needs to get done, motivation really is key. So people not hitting a slump or not, um, getting behind on things or development just because they're not that motivated anymore, that's something we absolutely cannot be doing in our project.

So gamification is a good idea for that. Another thing is, it is fundamentally rooted in the way we learn. If you look at how children learn, which is the most fundamental way of learning child play we call it.

Um, it is they will try something out, they will see how it goes, and then they will try again, try again, try again. So there is no shame in play, which is very interesting because we know from behavioral science and psychology that when people feel really safe to try things, they will grow and learn more. So if there's no shame in play and there's only learning through trial and error, it's the perfect environment to do new things, which is in essence what projects usually do, right?

We will introduce new things into an organization and hopefully that will benefit us for a long time to come. It's very often tied to strategic initiatives, maybe like organization-wide benefits that we want to reap. And what better idea to really create a psychologically safe and shame-free environment for people to get the best ideas out there.

Not just produce some sort of solution, but like the best, most innovative solution for us. So really cool. How do we do it?

In essence, there are, I would say, four different sections of things that we do in game design that can be applied, um, very differently. I will show you a couple of examples after this, but in essence, it's about making it look like a game. And if you're thinking of role playing games like RPGs or like, I dunno, any other sort of like computer game that you're playing, that's probably the way to go with, uh, thinking how it could look like.

So it's about points and badges. For instance, we will have in this the agile element of visual management. So we will make, um, milestones visual.

The, the progress and the status of things becomes more tangible because we will use, um, points that can be accumulated. We will have badges to show how far people have come. And this is also a sort of a cultural motivator because if I can wear my badge prominently, if that is digital on screen or just like have it on some sort of physical board in, in my team room, um, I will, I will be the king, right?

People will be looking at me like, oh my God, look at that. She got that badge. She must be amazing, right?

So it's a sort of a cultural thing where we feel like we have gained some sort of status in a group and that is something that just motivates us as, um, beings who like to be in groups and feel good about themselves while doing so, right? It's, it's a thing that will also boost morale and it will boost my, my, um, my thinking about myself in the sense of I have, I have done this, I have the badge to show for it. Why can't I tackle that one?

Right? So that is self, uh, self-explanatory I guess. Then we have challenges and rewards.

Now, this already exists a bit in like, um, operational elements like, uh, if we look at incentives for instance, but when we're talking about game design or gamification, intelligence and rewards become very different because what we want is we want people to not be too comfortable, right? We want them to move into the learning zone and this only happens if they step across their own boundaries, but that makes us feel unsafe and it could involve making mistakes, right? So we need to be able to show them that it is actually worth it to grow your skills here and we will give you a motivator to do so.

Very often this is done for groups, so like team challenges or team rewards because one element as we've just, uh, learned about a game design is that there is competition. But when we're in a project and we actually want everybody to collaborate really well, having competition doesn't always make it better. So in this sense, we'll use challenges that can be applied to groups and where we can have people collaborate and we will reward them for collaborating, well, for instance, for sharing their knowledge, for instance.

Um, so we are going to be rewarding things that we might not necessarily reward in the sense of like classic traditional incentives, like how many things did you get done this year? And so on. So it's more about behavior that we want to, um, that we want to reward.

And then there is leaderboards. Leaderboards are a bit tricky sometimes because it goes into that same area of competition, which is not always what we want. Um, but it is a thing that can help, for instance, if we want to motivate people to invest in continuous improvement.

So if we have a, a project for instance that doesn't go on for a month, but maybe a bit longer, right? Like a half a year or a year long project, at least it really makes sense to have leaderboards but then have leaderboards on on different things. So I don't need to like only reward those people that are good at that one arbitrary thing, but like have a couple of different options for people to really excel to drive their performance.

And this is a very personal motivator because me seeing my name at the top of that leaderboard will motivate me a lot. Um, of course it's also a bit status, but it's less that visual status maybe that points and badges can do because I can accumulate those and getting to the top of the leaderboard and staying there is just one thing, right? So it's a, it's a very personal thing and it also ties to whether that leaderboard actually does something for me.

So if it's a leaderboard for instance on collaboration, I would probably want to be at the top of it, but it's a, if it's a leader bar but something else I might not care about it, right? So it needs to be a personal motivator for it to click. And then of course the fourth element in anything we do, whether that is agile or project is feedback.

And feedback is also interestingly a big part of game design because as we have learned, there is a lot of trying, playing, learning through trial and error, making mistakes. So if I want to get ahead, I need to understand where my mistakes have been. So giving feedback really gives me transparency about the goal.

What, what should I have done? What should I have done differently maybe, and how can I excel the next time? How can I meet the goal the next time?

So it's about understanding skill gaps and this is a motivator that will fuel engagement because continuous feedback will then help me continuously achieve things which is continuous engagement, which will motivate me, right? So this is the long term thing basically that we want to do. So now that we've looked at the power of game design or gamification and the elements of gamification, let's put this into a project and into an agile context 'cause that's what we're here for, right?

Agile project management. So what is next? The easiest way to quickly add in gamification into your project or your adult project is by uh, just adding it to the adult events that you're probably, or hopefully doing anyway.

So you could have some sort of planning sessions, whether that is like a team level iteration planning or sprint planning or however you wanna call it or whether that's like project level planning, it doesn't matter. So when you are actually going into that, there are a lot of techniques that you might already use that maybe you didn't even know were gamification in the first place. So having point-based games poker for instance, yeah, so, uh, story, uh, user, uh, user story points and planning poker is actually gamification 'cause it takes something that's actually pretty serious seeing how much we can get done in the next week or the next sprint or the next iteration.

But we're using fun, funny, colorful cards and we're doing it in a poker based game format, right? So it's, it's making it fun but it should still not distract from what we're doing, which is effort estimation, right? So this is the perfect combination for instance of gamification trying to make something that we have to do anyway, make it fun, but we still want to have results, right?

So it can't just all be games. And if we're looking at this, this is I think one of the main issues that we have and we want to try to gamify things a bit. If people from outside, especially like management or upper management that don't have the time to really sit around and see what we're doing in detail, if they come around the corner and they see us playing poker, they'll be like, are they even working?

Right? So we will tackle that at a later stage in this presentation. But for now, keep in mind that might be part of the problem.

If it looks like too fun, people might think we're not working so we need to make sure that we are still having results. So this is why very often, even if it's gamified, we will have somebody like an agile coach or team coach or we might even call him a game master, doesn't really matter to facilitate what's going on to make sure that we are not getting distracted playing and we are actually arriving at what we want, which is in this case planning poker effort estimations. Another thing that we could do when we are setting up our planning session is to include a small topic of team-based challenges.

So let's say um, we are setting an iteration goal anyway, or a sprint goal, you might know that term better, then it actually makes sense to put in a challenge and a reward for that for, so for instance, we could do something like um, um, objectives and key results related thing in the sense of we don't wanna get a hundred percent necessarily, that will be amazing, but it's not a perfect world and we know it. So how about 80? Let's say 80% and if we reach that 80% it will be an instant pizza party for everyone.

So it's little things like this that actually are the challenges and awards we're looking at. We will not be looking at buying everybody a Ferrari, right? We'll be looking at small things that motivate us, that keep us going, but that they're not so high stakes that people get frustrated.

And on the other side also not that high stakes that it's just too expensive to do it, right? We need to have the business sense in mind as well there. So not too expensive small motivators.

Um, things that just make me happy and keep me going. Basically this would be an example for team-based challenges and if we are looking at more of those, what about daily or standup meetings? So it doesn't matter whether we're doing like daily scrums or standup meetings from Lean or Kanban or a mixture of that or if we're standing up at all because I've seen a lot of standup meetings where nobody stands, which is fun, but okay.

Um, things that we do there is we will probably use a visual task board anyway, right? Um, we should in agile with visual management, but if we're doing it in a project, it might contain some, a couple of more like progress trackers on it. We'll probably be looking at a couple more metrics maybe than we do like in our general like um, operational team delivery processes because we are like set for time and, and um, and iteration constraints, right?

The project can only go so long and after that it's disbanded so there's more crunch around time. So we'll have a couple more progress tracking metrics going on and that is the easiest thing to just transform into uh, a sort of progress tracking that will encourage daily achievements or micro rewards. We might call it kudos is an example of that.

Kudos are something that I personally loved that that happened. Usually a person did something that was amazing and I wanna give them kudos for it in the sense of I want to recognize they did an awesome thing and it's a feedback type of reward where I will just say, I'm really grateful that you did this, you helped me on this, uh, and so on. And these are like small kinds of achievements we can track as well.

So we will not only be tracking progress towards goals, but also maybe progress towards um, team values like collaboration, helping each other out and so on. And then deliver kudos to each other every day as part of the daily standup can be a small thing. We all know a daily standup shouldn't take too long, but it really motivates people and it will bring a sort of gamification element into it if we actually also track it.

For instance, we could do points, we can do smiley stickers, you won't believe it, but it's the child in us that responds and loves it. So stuff like that actually really makes a difference. Uh, having funny memes as well.

Still, still a runner, still a good thing to do. So what else can we do retrospective If we're sitting in retrospectives, everything is basically about feedback already anyway, so why not add to that? Um, doing like our serious retrospective, like everything that was tough, everything that we have to improve on, everything that went really well.

Um, let's get that checked out and after we've done that, try to go for maybe a bit lighter, um, stuff in your retrospective to basically round up and end your retrospective. So I would put it at the end, um, after all the serious things have been discussed basically and all the, the items that we want to do, um, have been created and then maybe use a fun voting tool. Uh, digital voting tool works best even if we are physically co-located, it's just easy to pull it up on your phone for instance.

There are a couple out there. I will not necessarily tell you this one is the best 'cause it really depends on what you need, but something that is visual that is fun, that is fast, that does not involve people setting up like really terribly uh, hard to crack accounts. So something that that is easy to use and something that's colorful because it needs to be gamified, right?

So that would be a good idea. We could use this to give feedback for instance, have like uh, star voting. Um, how did you think this retrospective went?

How did you think the iteration went or the sprint went? Um, and we can use different sort of icons for that to make it fun and change these out from time to time. Another thing that really resonated with uh, with teams in a lot of projects that I was on was to have voting tools for new ideas because you all know it, we go into that retrospective, there's like so much you want to actually change and challenge so much to improve on.

And you have that list of like 50 items or whatever and actually that's way too much to tackle anyway. We need to prioritize and why not prioritize by using digital voting tool. So voting for ideas and then maybe have some sort of like reward for the person whose ideas got voted on most for that iteration and so on.

That could be a cool gamification idea. Another thing would be to have these like action items, um, to actually like have progress bars for them to check follow who, because we all know that daily business just sometimes gets in the way and then in the end these improvements, they're the least prioritized, right? So that is a sad thing because if we improve on our collaboration on our internal processes, it will actually help us to produce stuff faster next time.

But very often the pressure to produce results or features or whatever just gets so high that we forget about our action items that we wanted to do and they just get pulled from iteration to iteration. So let's try to at least have a little bit of focus on that by having these progress bars, by putting them up visually on our physical or digital dashboards. And then say let's say if we reach 80%, if we reach 90%, like have a tiered thing going on, there will be some sort of rewards that will happen if we actually achieve that.

So you see it's always the same thing. Make it fun, make it colorful, make it easy to access, take the shame out of it, put the game the fun into it, but still have end results. Motivate people.

That's what we want to do. So this has us been looking at adult events. Now might be that you're not using adult events in your project, um, might also be that you are looking for bit more serious things that you can use gamification for maybe even bigger than just like team events or project events.

So let us have a look at pro project challenges, typical project challenges. And it doesn't matter if it's an agile project or a not so agile project or whatever you wanna call it. Um, the things that are usually the problem in projects are the same.

Um, when you're agile, sometimes it's even harder to be honest because not everybody might be agile or agile. Maturity is not that high yet. So let's have a look.

So the first thing I think in projects that happens, especially in very long project is maintaining momentum is very hard. And this especially touches projects that are about innovation, new things, solutions that we didn't think of before and where we want to be really innovative. But then after time gets in the way, sometimes the constraints get so tight that we just, we can't think out of the box anymore.

So maintaining that innovation and that that momentum that we had in the beginning where we had like bright eyes and huge ideas on how to change the world, it would be really nice if we could, could still get there and if that's not possible, at least have the motivation to keep going. So what is really cool for this is something that helps me to keep going and motivates me to keep going, right? So a streak is really cool.

We all know it probably from our uh, fitness wearables, from whatever other things we have. If we have a streak, like for instance, I logged in every day and I got a small reward for it, which might be completely digital and maybe it's not even money or whatever, it's like actually just an intangible thing, but it was colorful and made me happy, then I would probably want to log in tomorrow again and the day after and the day after. And I would be really sad if I had kept that going for like two weeks and then just because I missed a day I didn't do it right.

There are a lot of apps out there that will use this concept to motivate people. Um, and if you've used them enough, you might also know that sometimes it gets tiring and if you miss a day really frustrating and then you might never do it again. But still it's a cool idea to motivate teams or motivate people to uh, reward consistent performance.

And in project, the thing about this is very often when we're talking about um, what actually is good performance, people will say, well when lines are going up, we are performing well, but actually it is way better to achieve a good level of quality performance and then stay at that level because nobody can get better and better and better. That's just the road to burnout, right? And we want our teams and projects to have a consistent level of good quality output.

So we will encourage steady progress, we will encourage consistent performance. So what we want is a team that will consistently put out good quality work and the output is consistently the same amount. This is better than a team that will race to the finish line to get something done and after that will be sick for two weeks, right?

That's not helpful at all. Specifically if our project like the set timeframe. So use things like burn charts, meters for velocity and capacity or lead time that you might be using anyway.

And if we can get for instance those, those metrics to be within a very consistent strip, like let's say the velocity is always between this amount and that amount. Um, the capacity is always the same per day divided. Uh, basically the, the median is always this much, um, work or effort points a day and we don't strain more than 20% or down.

We will get a reward at the end of an iteration. And if we can keep that up for at least three or four iterations, the price will be a bit bigger. So this will really help us to not overwork ourselves very helpful and also to consistently be motivated to continue.

Next thing that is very often a project challenge is aligning stakeholder expectations. Um, and I put that double in there probably because it's so important. So aligning stakeholder expectations to maybe expectations that the team might have.

Uh, we all know they can be wildly different, right? What is stakeholder holder thinks is necessary or need to be done can be very different from that which a developer maybe thinks needs to be done. And developer is obviously here.

Anybody who helps working on a pro product, uh, doesn't need to be an IT developer, right? It's an adult developer. So what we want to do is we want to gamify requirements gathering now in adult that is already quite gamified if we use the adult tools for it.

So using personas for instance, um, fictional people that we make up that are based on user uh, representatives but that are also fun to create. We give them a name, right? Which can be fun, uh, shouldn't be stereotypical but should still be fun.

And then we will do stuff like journey maps, like really getting into the minds of these personas. What would they do? What would they want in our product and so on.

Um, that is in essence a gamification thing. Also prioritization with point-based broker. You already know that probably, but there is also one that's called buy a feature, which is really interesting because it's done with stakeholders instead.

So stakeholders will gather and they will see for instance all of the things that we need to do very often this will be in a product backlog for instance, or it will be a feature list and then everybody will get like 100 fictional euros, dollars, whatever. And they will be able to buy features with this. And we will probably tell them this feature is this size, this feature is this size, this feature is this size.

So based on effort we'll have given them dollar amounts or euro amounts and they can buy stuff with it, which will force them to prioritize in essence, right? And to really think about do I really want this 'cause I only have this much money left, maybe they need to go to another person and talk to them about how important this thing is and maybe they can pull the resources and so on. So it helps with collaboration, um, understanding priority and when the development team can be there and just sit through that and have a look at what they're doing and why they're making these decisions, it can really help with alignment as well because they will understand why stakeholders will want certain things.

So that's a cool thing to do. And we called it stakeholder engagement gains because yes, I know sitting there and calling it requirements engineering session, that is basically what it might be. But if you call it stakeholder engagement games, it just gets fun and words make a difference.

It changes a thing in our brain, right? So that can already happen and make us happy. But words alone are not best, are not enough, right?

So we need to have cool names for workshops but we also need to have cool, um, techniques that we use so that it will still be found otherwise it will feel set up and not real and that's not a good thing. So following through on the cool name, having a couple of cool techniques like a bio feature for instance, can really make a difference. So actually these are not big things.

So you can see that there are just small things that we could integrate into stuff that we're already doing in the project anyway, which is key. 'cause if we have to set up like a whole new elaborate kind of gamification thing, that's not what our time and money is for in the project, right? So always connecting it to things that we're already doing anyway, changing and turning them those into gamified elements, that's what we want.

Another thing that we very often want is mindset shifts. Especially if we are in agile transformation project or projects that will introduce new ideas, new mindsets, agile mindsets into an organization or that's at least what we're trying to do, right? So very often we have a problem with change.

Uh, change is uncomfortable. Everything new is scary, everything that is new can go wrong. Um, we might not know how to deal with this because we have never done this before.

And so, so in essence, when we feel safe again, we will accept a mindset shift. And how do we do this Well by telling people that it is okay to fail, fail, but also by giving people time and appreciation for when they actually do change something. So what very often worked in projects that I was in was something called change management quests or we called it change management quest.

And we would for instance, um, have gamified learning experiences. So we would say this is what we want you to learn. Let's say we're in an um, adult transformation and everybody should have down the basics of a couple of adult approaches.

For instance, we would say, so you can do things like you can do a scrum training, you could do a ban training and you can do a couple of add-on trainings like maybe reaching a couple of levels. You could also take the exam to call yourself a product owner or scrum master or whatever. So all of these things could be like tiered rewards and we would set that up as such and visualize them.

Um, so if you go through this point and then you can go through that next and to that next here at the end is a reward for instance. Or we could for instance also reward adult values or behaviors when they're displayed. Um, that is a bit more tricky because it's basically rewarding culture when it is being lived, right?

So I'll give you an example of that on the next slide where we'll be talking about um, how to implement uh, value and how to do peer reviews. So keep your eye out on that if that is something you're interested in. We'll get to that in just a second.

But basically we are rewarding good behavior you could say. So we've talked about things we can do on team levels or in adult events. We talked about tackling project challenges with gamification and that will was one too fast.

Let us go here and have a look at large gamification projects or large initiatives and I want to use gamification for this. Uh, let me just quickly see that I haven't double clicked. Yes.

Okay, so this is the next one. So what can we do? So we've stayed mostly at teamwork project level until now.

So we've talked about iteration based challenges. We've talked about skill development, like having um, uh, basically tiered uh, rewards for going through certain like skill trainings. We talked about daily engagement recognition for instance, rewarding stuff that happens every day in the daily standup or things that will happen continuously, for instance, like continuous delivery of quality output.

But what if I want to take that to the next level? What if I want to, um, use gamification in a bigger initiative? What if my project is part of a bigger program, for instance, for agile transformation or what if it even reaches up to the portfolio level, which would basically mean that you're rolling something out across the whole organization, I would say.

But that's the levels we can talk about in the sense of project management or PPM, right? Project program portfolio management. So if I'm looking at the program level, it becomes more about stuff that happens between teams.

So we would have co cross-functional or inter-team competitions, uh, always friendly competitions. Mind you never in the sense of uh, that there are like definitive losers or something. That's not what it's about, right?

We want to have rewards for that. And I'll show you a couple of ideas that we can use this for in a minute. Um, on how to make it a friendly competition.

We would maybe have something like release train gamification if that's a thing we're using. It's a term uh, from safe obviously. But anything that could be the same as that is, for instance, if we have the output of several projects and we have released them together, then we could have a party or something that would already be some sort of uh, similar thing for the program level.

We could reward quarterly achievements as a whole program. So when we as a program get to our objectives and key results, for instance, if we hit our deadlines there, if we hit our goals there, we might reward all of the projects that helped, um, helped us get there. Um, and then we have the portfolio level.

This is where we're talking about organization wide things. We could have organization wide leaderboards, which would lend itself very well actually to agile behaviors or like new, uh, new ways of thinking that we want to introduce or maybe just like rewarding values like collaboration generally. Um, then we want to have strategic goal alignment games, which means that we will set goals for us that align with the strategy that our organization wants to put out.

And when we reach those, we will get recognized for it, not just in front of like 10 people but like in front of the whole company. So it would be some sort of like event, which is why we call it games very often, where we will actually pull people up to a stage and say thank you and give them a reward for something. And then we could have annual innovation or transformation quests.

Uh, another way to say this would be hackathons if you want the more boring word or innovation days. So that is a thing we could do as well. Obviously this is not something we can only do at the portfolio level.

So let us have a look at where we could put these things into action and how they can actually benefit us on our projects as well. So if we want to implement gamification, what we want to do is we want to set clear objectives. We want to define specific goals for our gamification.

Um, for instance, do we want to reward behavior? Do we want to uh, reward other things? Uh, do what do we want to track?

And um, when we're tracking metrics, it's usually important that we don't just track because we can. So it should have a goal in mind and we should make sure that we align, gain game elements with the desired outcomes that we have. Just rewarding people for stuff 'cause we think it's fun.

Yeah, that's also gamification. But in a project we want alignment 'cause we don't have much time and budget, right? So that is important.

Then we want, uh, to make sure that we start small. We do not want to confuse people with too many things because you know how it is when you're starting a new game, right? It can be very confusing in the beginning.

Uh, we don't want that 'cause people still have to work, right? So we'll just start small, maybe have one or two gamified elements, maybe when this becomes more like used to to people, we will introduce a couple more. We'll gradually expand and always ask teams, uh, on feedback on other results.

Did this motivate you? Did this not motivate you? Without this feedback, don't introduce anything else.

Okay? Then next we want to make sure that we do actually measure iterations as well. So we want to track key metrics.

For instance, as I said, this continuous output is really important or having people not overextend themselves, but to deliver quality output, something like this is really inter uh, interesting to have a look at and that is one of the things I would definitely do, but I would also continuously refine this approach because if we do the same in every project, it's less of a game and more of business as usual, right? So it still needs to be a game. So we should tweak things from time to time.

And then we want to involve people who want to ask them what would motivate you? What would you like to be rewarded for? Um, collaborate with them on this gamification design that already can be a really fun step to take people along.

And that can be like already a gamified experience for people as well. And we want to make sure that the games actually resonate with culture and with preferences. So this is very important if you have like globally distributed teams because maybe for one culture something might be really cool and for another it might not be that important.

So be mindful of this and always ask people, did this work, did this motivate you? Why not? And these things will emerge on their own.

So now that we've talked about next steps, let us have a look what else is out there. So what else can we do when we're talking about gamification? I think it's interesting to see all of these like potential things that you could do, but I think one of the things that you, um, that will help you most is probably also having real life examples.

And this is what I want to give you next. So bear with me and we will have a look at what we can do next. Alright, so mm-hmm there, it's, let's have a look at how to enhance project and team collaboration.

And now we want to have real examples. So it doesn't matter what kind of a project you're in, if you're a project or program, whatever, you just need to make sure that it happens at the right level basically and that you make the rewards fitting and that you make it fitting to culture and to cross functional team things, right? But the basic basics are the same.

So we want to for instance, help people, um, gain skills because it's important for them in a new project, in a new initiative to grow and learn. Um, and we want them to adapt new things, new behaviors as well. So nothing better than a learning path or skill treat.

We'll know it in games. It's, you can have skills that build on each other and at the end you will get a reward for it, right? You will get some sort of thing that makes your look your player character better, faster and so on.

So what we want is we want to visualize team member growth. So this is a individual thing, right? This is for a single person and it'll help them to value continuous learning, but it will also improve if we give people the option of having mentor mentee relationships and then to guide each other maybe as a team or as um, as a mentor, as a mentee to get through these skill trees.

So this is where we talk about, for instance, collaborating with your, um, team leads or collaborating with your, with your agile coaches or your team coaches and setting incentives basically based on these skills that accumulate during the project and integrate them into reviews and rewards that we get. Then we want to have things like team level rewards where we move away from the individual and now want more collaboration. So we will have team dashboards probably in an agile project anyway, so let's gamify them.

Um, the thing that has been really fun and very helpful actually is to give people power up. So you can see the language is just stolen from games basically a lot of the time. So what is a power up?

It's a thing that I can use to, for a short amount of time, be better at something, right? For instance, when Mario eats the mushroom or whatever, right? You know, from that water power op is or I hope you do 'cause that means you still know what Mario is all about.

So in that sense, we want to give people power ops or rewards for collaborative actions. For instance, I helped another person this iteration or in this project stage or whatever and then I will be awarded a power op if I'm lucky. Um, and we will do this usually based on peer review.

So another person will say, you know what Ruth, you've helped me so much this iteration. I want you award you a power op for collaboration, for helping, for, we should set the areas in which people can give power ops. And this power op for instance would say, um, that I get out of making coffee for everybody or like a small thing that will make me happy or I can have an hour early off work next week, uh, and so on.

So something that will actually benefit me that is a reward, but it shouldn't be too big because we don't want people to be sad if they don't get it right. We want to have small consistent motivation going on that helps most. And then we could have team goals and rewards for collaboration or commitment as a team when we fully committed, for instance, to this amount we can do and we will deliver it and we actually did that should be rewarded as a team, not necessarily single people, but then we all work together.

Everybody contributed in some way and we will only get the reward as a team, which means that we need to help each other also, right? So that is a cool thing to do. If we go a bit higher than that and to the project level, we want to have cross-functional quest.

So we want to make sure that we want to do things like hackathons, we want to do things like innovation days. Um, and this is suitable for specifically complex problems. So in every project there are those like really complex problems or things where stakeholders don't align or we just have an issue finding the real solution or uh, it's maybe we're even producing some sort of like software and there's a really big problem we can't get behind it.

Um, something like this, if we're talking um, uh, project, uh, development for instance, we will be accumulating those types of problems and issues, right? And then regularly setting maybe half a day or a day aside to get into groups, um, break up teams as they are working in the project and just cross-functionally putting people together a new, um, new teams basically for that specific hackathon or innovation day. And then having them crack crack those, those issues, having them have a go at a new innovative solution.

Very often we find that mixing people up and having them look at things from a fresh perspective sometimes really helps on getting solutions for these problems that have been bugging us for weeks now. And it will give us really good benefits in the sense of real solutions for problems we couldn't solve in the pop in the project before. Better quality products, better quality outputs because of that, making customers and stakeholders and users happier because of it.

But we should also give people the hackathon and or innovation date as a reward. 'cause it's usually a bit more unstructured and it usually includes something like food drink, right? Something that feels more like parly, less like work, but it's so fun to do and give us, gives us real results.

And then we could have things like innovator or motivator, uh, badges. Um, we could give out badges on a project level and maybe after every, um, stage and we could sit down and say, okay, so here are the awards. Have people vote anonymously on their phone.

And then we will call people up to a stage and give them like a badge for something. Maybe it also is tied to a small reward, but the badge itself is already a really nice reward and people will be proud of it and show it and be like, yeah, I got this reward for being the best innovator because I motivated the teams most this stage and so on. So that's a really cool thing to do as well.

Another thing we might want to implement is project level peer rewards. So, uh, we want to for instance, have maybe point systems going on and we would call these MVPs, uh, as an iterate, as an alternative to most valuable player. We'll call the most valuable peer and we will reward things that maybe we usually don't look at that much.

So for instance, we want to have, um, the person who was, was funniest, who cooked the best coffee, small things that everybody can achieve that makes sense and it usually is somebody else that's, that's going to be fun and they can get, uh, a badge for that maybe as well. Or we would have those people awarded that usually people don't see. Um, those are the people that make sure that everybody is running, everybody has what they need.

Um, the people that don't get a thanks so often and we would call this a secret achiever recognition. So, um, we would have anonymous voting for that and then we would, um, depending on if the person likes it or not, or if we want to make this public or not give out achievements for things that otherwise we might not recognize. This makes sure that we don't only reward people who are like, um, very high achievers in the sense of skills or output, but also softer skills, um, that we still need in a team so that people stay happy and stay motivated.

So now that we have talked so much about all of this beautiful gamification, um, I actually really want to hear your questions and I want to know what you guys are thinking, uh, whether you think you can apply it in your projects, in your agile projects, um, what is needed, what is still missing, what do you want to know? So I will be moving on to the question section. Thank you for listening to me and I hope that you will try gamification out in your next adult project.

Thank you.