Screaming in the Cloud - The Importance of the Platform-As-a-Product Mentality with Evelyn Osman

Episode Date: January 9, 2024

Evelyn Osman, Platform Engineering Manager at AutoScout24, joins Corey on Screaming in the Cloud to discuss the dire need for developers to agree on a standardized tool set in order to scale their projects and innovate quickly. Corey and Evelyn pick apart the new products being launched in cloud computing and discover a large disconnect between what the industry needs and what is actually being created. Evelyn shares her thoughts on why viewing platforms as products themselves forces developers to get into the minds of their users and produces a better end result.About EvelynEvelyn is a recovering improviser currently role-playing as a Platform Engineering Manager at Autoscout24 in Munich, Germany. While she says she specializes in AWS architecture and integration after spending 11 years with it, in truth she spends her days convincing engineers that a product mindset will make them hate their product managers less.Links Referenced:LinkedIn: https://www.linkedin.com/in/evelyn-osman/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn.

My guest today is Evelyn Osman, Engineering Manager at AutoScout24. Evelyn, thank you for joining me. Thank you very much, Corey. It's actually really fun to be on here. I have to say, one of the big reasons that I was enthused to talk to you is that you have been using AWS, to be direct, longer than I have. And that puts you in a somewhat rarefied position where AWS's customer base has absolutely exploded over the past 15 years that it's been around. But at the beginning, it was a very different type of thing. Nowadays, it seems like we've lost some of that

magic from the beginning. Where do you land on that whole topic? That's actually a really good point because I always like to say, you know, when I come into a room, you know, everybody's kind of doing introductions like, oh, you know, hey, I'm like, you know, I'm this director, I've done this X, Y, Z. And I always say like, oh, Evelyn, you know, engineering manager or architect or however. And then I say, you know, I've been working with AWS since, you know, 11, 12 years or now I can't quite remember. Time becomes a flat circle. The pandemic didn't help.

Yeah. I just like, I look at the year now, I'm like, Jesus, it's been that long. Yeah. And usually, like, you know, you get some odd looks like, oh my God, you must be a sage. And for me, um, you see how different services kind of like have just been reinventions of another one, or they just take a managed service and make another managed service around it. Uh, so I feel that there's a lot of where it's just, you know, wrapping up a pretty bow and calling something different. It feels like. That's what I've been low-key asking people for a while now over the past year. Namely, what is the most foundational, interesting thing that AWS has done lately that winds up solving for this problem of whatever it is you do for as a company?

What is it that's foundationally made things better that AWS has put out, the last service? What was it? And the answers I get are all depressingly far in the past, I have to say. What's yours? Honestly, I think the biggest game changer I remember experiencing was at an AWS summit in Stockholm

where they announced Lambda. Lambda was announced before I even got into this space as an example of how far back things were. And you're right, that was transformative. That was awesome. Yeah, precisely. Because before, you know, we were always like trying to figure out,

okay, how do we like launch an instance, run some short code and then clean it up? Well, it's going to charge us for an hour. So we need to figure out, you know, how to pack everything into one instance, run for one hour. And then they announced Lambda and suddenly like, holy shit,

this is actually a game changer. We can actually write small functions that do specific things. And, you know, you go from like microservices like to really tiny serverless functions. So that was huge. And then DynamoDB along with that really kind of like transformed

the entire space for us in many ways. So back when I was at TIBCO, there was a few innovations around that. Even like one startup inside Tipco that quite literally their entire product was just Lambda functions. And

one of their problems was they wanted to sell in the marketplace and they couldn't figure out how to sell Lambda in the marketplace. It's kind of wild when we see just how far it's common, but how also how much they've announced that doesn't change that much to be direct for me. One of the big changes that I remember that,

that really made things better for customers, though it took a couple of years was EFS. And even that's a little bit embarrassing because all that is, is all right, we finally found a way to stuff a net app into us East one. So now NFS, just like you used to use it in the 90s and the knots can be done responsibly in the cloud and that on some level wasn't a feature launch so much as it was a concession to the ways that companies had built things and weren't likely to change

honestly i found the efs launch to be a bit embarrassing because like when you look closer at it you realize like the performance isn't actually that great oh it was horrible when it launched and when it would slam to a halt because you got the IOPS scaled with how much data you stored on it the documentation explicitly said to use DD to start loading a bunch of data onto it to increase the performance it's like but just sandbag the things so it does what you'd want and all that stuff got fixed but at the time it looked like it was clown shoes yeah and that that reminds me of like ebs is like gp2 when we're like you know we're talking like okay provision iops was a gp2 we just kept saying like just give yourself a really big volume for performance and i feel like they just kind of kept that with efs

and it took years for them to really iterate off of that yeah Yeah, so EFS was a huge thing. And I see us, we're still using it now today. And we're trying to integrate it, especially for data center migrations. But you always see that a lot of these were first more for like, no, data centers is a cloud. So first I had like AC2 Classic. That's where I started.

And I always like to tell a story that in my team, we're talking about using AWS. I was the only person fiercely against it because we did basically large data processing. Sorry, I forget the right words. Data analytics. There we go. I remember that too. When it first came out, it was, this sounds dangerous and scary.

And it's going to be a flash in the pan because who would ever trust their core compute infrastructure to some random third-party company, especially bookstore and yeah i think i got that one very wrong yeah exactly i was just like like no way you know i see all these all these articles talking like terrible disk performance and here i am where it's like it's my bread and butter and specialize in it you know i can i write code in my sleep and such yeah the interesting thing i saw was like first it was like your launch services, you know, to kind of replicate when you get a data center to make it feature comparable. And then it was taking all

these complex services and wrapping it up in a pretty bow as a managed service. Like EKS I think was the biggest one if we're looking at managed services. Technically, Elasticsearch, but I feel like that was the red-headed stepchild for quite some time.

Yeah, Elasticsearch was a weird one. It still is. It's not a pleasant service to run in any meaningful sense. What people actually want is the next enhancement that would excite everyone is, I want a serverless version of this thing where I can just point at a bunch of data, I hit an API that I don't have to manage and get Elasticsearch results back from. They finally launched a serverless offering that's anything but. You have to still provision compute units for it. So apparently the word serverless just means managed service over at AWS land now. And it ties into the increasing sense of disappointment I've had with almost all of their recent launches versus what I thought they could have been. Yeah. The interesting thing about Elasticsearch is a couple of years ago,

they came out with OpenSearch, a competing Elasticsearch after Elasticsearch kind of gave them a finger and changed their licensing. And OpenSearch actually became a really great offering if you run it yourself. But if you use their managed service, you kind of lose all the benefits in a way. I'm curious as well to get your take on what I've been seeing that I think can only be described as an internal shift where it's almost as if there's been a decree passed down that every service has

to run its own P&L or whatnot. And as a result, everything that gets put out seems to be monetized in weird ways, even when I'd argue it shouldn't be. The classic example I like to use for this is AWS Config, where it charges you per evaluation, and that happens whenever a cloud resource changes. What that means is that by using the cloud dynamically, the way that they supposedly want us to do, we wind up paying a fee for that as a result. And it's not like anyone is using that service in isolation.

It is definitionally being used as people are using other cloud resources. So why does it cost money? And the answer is, is because lately, everything they put out costs money. Yeah, pretty simple. Oftentimes, there's like R&D and it goes into it, but the charges seem a bit odd. I think an S3 lens was, I mean, that's like, you know, if we're talking about services, that was actually a really nice one, very nice holistic overview, you know, like I can drill into my data lake and like look into things. But if you actually want to get anything useful, you have to pay for it.

Yeah. Everything seems to, for one reason or another, be stuck in this place where, well, if you wanted to use it, it's going to cost. And what that means is that it gets harder and harder to do anything that even remotely resembles being able to wind up figuring out where's the spend going or what's it going to cost me as time goes on because it's it's not just the what are the resources i'm spending i'm going to cost what are the second third and fourth order effects of that and the honest answer is is well nobody knows you're going to have to basically run an experiment and find out. Yeah, no, true. So what I just got, what we actually are doing is because we're trying to figure out how to track all these

costs, we built an in-house cost allocation solution so we could track all that. Now, AWS has actually improved cost score quite a bit, and even I think Billing Conductor was one that came out where it allows you to do a custom tiered account pricing model where you can kind of do the same thing. But even that, also there is a cost with it. And I think billing conductor was one that came out where it allows you to do a custom tiered account pricing model where you can kind of do the same thing.

But even that also, there is a cost with it. And I think that was trying to compete with other vendors doing similar solutions. But it still is something where we see that either there's like arbitrarily low pricing there or the cost itself doesn't really quite make sense. Like AWS Conf, like you mentioned, it's a terrific service. We try to use it for compliance enforcement and other things catching bad behavior. But then as soon as people see the price tag,

we just run away from it. So a lot of the security services themselves, actually, the cost kind of like skyrockets tremendously when you start trying to use it across a large organization. And oftentimes the organization isn't actually that large. Yeah, it gets to this point where, especially in small environments, you have to spend more energy and money chasing down what the cost is than you're actually spending on the thing.

There were blog posts early on that, oh, here's how you analyze your bill with Redshift. And that was a minimum of $750 a month. It's, well, I'm guessing that that's not really for my $50 a month account. Yeah. No, precisely. I remember seeing that this entire ETL process is just to analyze your invoice. Cost of support is fantastic. But at the end of the day, what you're actually looking at is infinitively small compared to all the data in that report. I think oftentimes it's simply, you know, like, I just want to look at my resources and allocate them in a multidimensional way, which actually is really that multidimensional when you think about it.

Increasingly, Cost Explorer has gotten better. It's not a new service, but every iteration seems to improve it to a point now where I'm talking to folks and they're having a hard time justifying the most of the tools in the cost optimization space just because, okay, they want a percentage of my spend on AWS to basically be a slightly better version of a thing that's already improving and works for free. That doesn't necessarily make sense. And I feel like that's what you get trapped into when you start going down the VC path and the cost optimization space. You've got to wind up having a revenue model and an offering that scales through software. And I thought originally I was going to be doing something like that. At this point, I'm unconvinced that anything like that is really tenable. Yeah. When you're a small organization, you're trying to optimize, you might not have the expertise or the knowledge to do so. So when one of these small consultancies comes along saying, Hey, we're going to charge you a really small percentage of your invoice. Like, okay,

great. And that's like, you know, like a few hundred a month to make sure I'm fully optimized and I'm saving, you know, far more than that. But as soon as your invoice turns into, you know, it's like a hundred thousand or 300,000 or more, that percentage becomes rather significant. And I've had vendors come to me and talk to me and say, hey, for a small percentage, we're going to do this machine learning, AI optimization for you. You don't have to do anything. We guarantee buybacks to your RIs.

And as soon as you look at the price tag with it, we just have to walk away. Or oftentimes we look at it and there are truly very simple ways to do it on your own if you just kind of put some thought into it. While we wound up talking a bit before this show, you taught me something new about Gamelift, which I think is a different problem that AWS has been dealing with lately.

I've never paid much attention to it because it is, as I assume from what it says on the tin, it's, oh, it's a service for just running a whole bunch of games at scale. I'm not generally doing that. My favorite computer game remains to be Twitter at this point, but that's okay. What is Gameloft, though? Because you wound up shining a different light on it, which makes me annoyed that Amazon Marketing has not pointed this out. Yeah, so I'll preface this by saying I'm not an expert on Gameloft.

I haven't even spun it up myself because there's quite a bit of price. I learned this while chatting with an SA who works in the gaming space. And I kind of want to back up a second. If you think about World of Warcraft, all you have are thousands of game clients all over the world playing the same game on the same server in the same instance. And you need to make sure, you know, that when I'm running and you're running, that we know that we're going to reach the same point at the same time. Or if there's one object in that room, that only one of us can get it. So all these servers are doing is tracking state across thousands of clients. And GameLift, when you think about your dedicated game servers,

it really is just multi-region distributed state management. Like at the basic, that's really what it is. Now there's quite a bit more happening within GameLift, but that's what I was going to explain. It's just state management. And there are far more use cases for it than just for video games. That's maddening to me because having a global session state store, for lack of a better term, is something that so many customers have built themselves repeatedly. They can

build it on top of primitives like Dynamo DB global tables or alternately you have a dedicated region where that thing has to live and everything far away takes forever to round trip. If they've solved some of those things, why on earth would they bury it under a gaming branded service? Like offer that primitive to the rest of us

because that's useful. No, absolutely. And honestly, I wouldn't be surprised if you peel back the curtain with Gamelift, you'll find a lot of several other, you know, AWS services that it's just built on top of. I kind of mentioned earlier

is like what I see now with innovation is like we just see other services packaged together and releases a new product. Yeah, IoT had the same problem going on for years where there was a lot of really good stuff buried in there like IoT events. People were talking about using that for things like browser extensions and whatnot. But you need to be explicitly told that that's a thing that exists and is handy. Otherwise, you'd never know it was there because, well, I'm not building anything that's IoT related. Why would I bother? It feels like that was one direction that they tended to go in.

And now they take existing services that are kind of milquetoast, if I'm being honest, and then saying, oh, like we have comprehend that does effectively detection of themes, keywords and whatnot from text. We're going to wind up re-releasing that as comprehend medical, same type of thing, but now focused on a particular vertical. Seems to me that instead of being a specific service for that vertical, just improve the baseline, the service, and offer HIPAA compliance if it didn't exist already, and you're mostly there. But what do I know? I'm not a product manager trying to get promoted. No, that's true.

I was going to mention that maybe it's the HIPAA compliance, but actually a lot of their services already have HIPAA compliance. And I stared far too long at that compliance section on AWS's site to know this, but you know, a lot of them are actually HIPAA compliant, they're PCI compliant and ISO compliant and everything. So I'm actually really intrigued to know why they would take that advantage. I just checked. Amazon Comprehend is itself HIPAA compliant and is certified to hold personal health information,

PHI, private health information, whatever the acronym stands for. Now, what's the difference then between that and medical? In fact, the HIPAA section says for Comprehend Medical, for guidance, see the previous section on Amazon Comprehend. So there's no difference from a regulatory point of view. That's fascinating. I am intrigued, because I do know that within

AWS, they have different segments. There's digital native business, there's enterprise, there's startup. I'm curious how things look over the engineering side. I'm going to talk to somebody about this now. Yeah, it's the, I almost wonder on some level, it feels like, well, we wound up building this thing and in the

hopes that someone would use it for something. And well, if we just use different words, it checks a box and some analysts chart somewhere. I don't know. I mean, I hate to sound that negative about it, but it's increasingly when I talk to customers who are active in these spaces around the industry, vertical targeted stuff aimed at their industry, they're like, yeah, we took a look at it. It was adorable. We're not using it that way. We're going to use either the baseline version or we're going to work with someone who actively gets our industry. And I've heard that repeated about three or four different releases that they've put out across the board of what they've been doing. It feels like it is a misunderstanding between what the world needs and what

they're able to, or willing to build for us. No, it's true. I wouldn't be surprised if we go far enough. It couldn't probably be. There's just a product manager saying like, we have to advertise directly to this industry.

And if you look at it, you know, it's in the back end, you know, it's just an engineer, you know, kicking off a build and just changing the name from Comprehend to Comprehend Medical. And on some level, too, they're moving a lot more slowly than they used to.

There was a time where they were, in many cases, if not the first mover, the first one to do it well. Take CodeWhisperer, their AI-powered coding assistant. thing if GitHub Copilot hadn't beaten them to every punch, come out with new features, and frankly, in head-to-head experiments that I've run, came out way better as a product than what CodeWhisperer is. And while I'd like to say that this is great, but it's too little too late. And when I talk to engineers, they're very excited about what Copilot can do. And the only people I see who are even talking about CodeWhisperer work at AWS. No, it's true.

And so I think what's happening, and this is my opinion, is that first you had to be able to launch really innovative new services, you know, that kind of like say, ah, it's a whole new way of running your workloads in the cloud. Instead of, you know,

basically hiring a whole team, you know, just click a button, you have your instance, you use it, it's all software, blah, blah, blah, blah. And then they went towards serverless and then IoT. And then it's sort of targeting large data lakes. And then eventually that kind of run backwards towards security after the upteenth S3 data leak.

Oh, yeah. And especially now, so they had a hit in some corners with SageMaker. So now there are 40 services all starting with the word SageMaker. That's always pleasant. Yeah, precisely. And what I kind of noticed is now they're actually having to run even further back because they caught all the corporations that could pivot to the cloud. They caught all the startups who started in the cloud. And now they're going for the larger behemoths who have massive data centers, and they don't want

to innovate. They just want to reduce this massive sysadmin team. I always like to use the example of Bare Metal. When that came out in 2019, we all kind of scratched our head. I'm like, really? I can see where it makes some

sense just for very specific workloads that involve things like specific capabilities of processors that don't work under emulation in some weird way. But it's also such a weird niche that I'm sure it's there for someone. My default assumption, just given the breadth of AWS's customer base, is that whenever I see something that they just announced, well, OK, it's clearly not for me. That doesn't mean it's not meeting the needs of someone who looks nothing like me but increasingly as i start exploring the industry and these services have a time to percolate in the popular imagination and i still don't see anything interesting coming out with it it really makes you start to wonder yeah but then like i think like roughly a year or something right after bare metal came out they announced outposts

so then it was like another way to just stay within your data center and be in the cloud. Yeah, there's a bunch of different ways they have that, okay, here's ways you can run AWS services on-prem, but still pay us by the hour for the privilege of running things that you have living in your facility. And that doesn't seem like it's quite fair.

That's exactly it. So I feel like now it's sort of a diminished returns and sort of doing more cloud native work compared to these huge opportunities, which is everybody who still has a data center for various reasons, or they're cloud native and they grow so big that they actually start running their own data centers.

I want to call out as well, before we wind up being accused of being oblivious, that we are recording this before reInvent. So it's entirely possible, I hope this happens, that they announce something or several somethings that make this look ridiculous and we're embarrassed to have had this conversation. And yeah, they're totally getting it now and they have completely surprised us with stuff that's going to be transformative for almost every customer. I've been expecting and hoping for that for the last three or four reinvents now and i haven't gotten it that's true and i think there's even uh new service launches that actually are missing fairly obvious things in a way like mine is the managed workflow for amazon so manager flow sorry so we

were using data pipeline for you know this detailed process. It was an in-house tool that we built. We do platform engineering. And it was deprecated. So we looked at a news with a replacement. So we looked at Airflow. And we decided this is the way to go. We want to use managed because we don't want to maintain our own infrastructure. And the problem we ran into is that it doesn't have support for shared VPCs and we actually talked to our account team and they were confused because they said like,

well, every news service should be supporting this natively but it just didn't have it. So that's kind of what I kind of found is like it feels that sometimes it's getting rushed out the door to actually have a new managed service or a new service launched out but they're also sort of cutting some corners just to actually make sure it's packaged up out the door and it'll actually have a new managed service or a new service launched out.

But they're also sort of cutting some corners just to actually make sure it's packaged up and ready to go. When I'm looking at this and seeing how this stuff gets packaged and how it's built out, I start to understand a pattern that I've been relatively down on across the board. I'm curious to get your take

because you work at a fairly sizable company as an engineering manager, running teams of people who do this sort of thing where do you land on the idea of companies building internal platforms to wrap around the offerings that the cloud service providers that they use make available to them so my opinion is that you need to build out some form of standardized tool set in order to actually be able to innovate quickly now this sounds counterintuitive because everybody's like oh you to actually be able to innovate quickly. Now this sounds counterintuitive because everybody's like, oh, you know, if I want to innovate, I should be able to

just experiment and try out everything and use what works and just release it. And that's great in a startup mentality, you know, it's like 5,000 engineers working to build something. But when you have instead of five engineers, you have five teams of five engineers each and every single team does something totally different. You know, one uses Scala, another one TypeScript, the other one, you know,.NET. And then the last one, you know, comes in, you know, saying they're still using Ruby. And then next thing you know, you know, you have like incredibly divergent platforms for services. And if you want to do any sort of like hiring or cross-training, it becomes incredibly difficult. And actually, as the organization grows, you want to hire talent.

And so you're going to have to hire, you know, developer for this team, you have to hire, you know, Ruby developer for this one, Scala guy here, Node.js guy over there. And so this is where we say, okay, let's agree. We're going to be a Scala shop. Great. Great. Are we running serverless? Are we running containerized? And you agree on those things. So that's already like the formation of it. And oftentimes you start up with DevOps. You say, I'm a DevOps team,

or we're doing a DevOps culture if you do it properly. But you always have this scaling issue where you start growing. And then how do you maintain that common tool set? And that's where we start looking at having the platform approach.

But I'm going to say it's platform as a product. That's the key. Yeah, that's a good way of framing it, because originally the entire world needed that. That's what RightScale was when EC2 first came out. It was a reimagining of the EC2 console that was actually usable. And in time, AWS improved that to the point where right scale didn't really have a place anymore in a way that it had previously. And that became a business challenge for them. But you have, what is it now, two, three hundred services that AWS has put out. And, okay, great.

Most companies are really only actively working with a handful of those. How do you make those available in a reasonable way to your teams in ways that aren't distracting, dangerous, etc.? I don't know the answer on that one. Yeah, that's true. So full disclosure, at AutoScout, we do platform engineering. So I'm part of the platform engineering group, and we build a platform for our product teams. It's kind of like you need to decide all those answers you know like are we going to be fully containerized okay then

great we're going to use fargate all right how do we do it so that developers don't actually don't need to think that they're running fargate workloads and that's like you know where it's really important to have those standardized abstractions that developers actually enjoy using. And I'd even say that before you start saying, ah, we're going to do a platform, you say, we should probably think about developer experience. Because you can do a developer experience without a platform. You can do that in a DevOps approach. It's basically build tools that makes it easy for developers to write code.

That's the first step for anything. It's just like, you have people writing the code, make sure that they can do the things easily and then look at how to operate it. That sure would be nice. There's a lack of focus on usability, especially when it comes to a number of developer tools that we see out there in the wild,

in that they're clearly built by people who understand the problem space super well, but they're designing these things to be used by people who just want to make the website work. They don't have the insight, the knowledge, the approach, any of it, nor should they necessarily be expected to. No, that's true. And what I see is a lot of the times it's a couple of really talented engineers who are just getting shit done. And they get shit done however they can.

So it's basically like if they're just trying to run the website, they're just going to write the code to get things out there and call it a day. And then somebody else comes along, has a heart attack when they see what's been done, and they're kind of stuck with it because there is no guardrails or paved path or however you want to call it. Yeah. I really hope, truly, that this is going to be something that we look back and laugh when this episode airs. That, oh yeah, we got it so wrong. Look at all the amazing stuff that came out of reInvent. Are you going to be there this year? I am going to be there this year. My condolences. I keep hoping people get to escape.

This is actually my first one in, I think, five years. So, I mean, the last time I was there was when everybody's going crazy over pins and I still have a bag of them. Yeah. That did seem like a hot second collectible moment, didn't it? Yeah. And then I think what the very last day as everybody's heading to replay, you could just go into the registration area. They just had like bags of them laying around to take. So all the competing, you know, to get the requirements for a pin was kind of moot.

Don't you hate it at some point where it's like, you feel like I'm going to finally get this crowning achievement? It's like, or just show up at the buffet at the end and grab one of everything. And wow, that would have saved me a lot of pain and trouble. Scavenger hunts are hard as I'm about to learn to my own detriment.

Yeah, not true. But I am really hoping that reInvent proves me wrong, embarrassingly wrong. And then all my colleagues can proceed to mock me for this ridiculous podcast that I made with you. But I am a fierce skeptic, optimistic nihilist, but still a nihilist. So we'll see how reInvent turns out. So I am curious, given your experience at more large companies than I tend to be embedded with for any period of time. How have you found that these large organizations tend to pick up new technologies? What does the adoption process look like? And honestly, if you feel like throwing some shade, how do they tend

to get it wrong? In most cases, I've seen it go terrible. Like it just blows up in their face. And I say that because a lot of the time an organization will say, hey, we're going to adopt this new way of organizing teams or developing products. And they look at all the practices. They say, okay, great. Product management is going to bring it in. They're going to structure things, how we do the planning. Here's some great charts and diagrams, but they don't really look at the culture aspect. And that's always where I've seen things fall apart. I've been in a room where, you know, our VP was really excited about team topologies and say, hey, we're going to adopt it. And then

an engineering manager proceeded to say, like, okay, you're responsible for this team. You're responsible for that team. You're responsible for this team. Talking to like a team of like five engineers, which doesn't really work at all or i think the the best example is devops you know where you say ah we're gonna adopt devops we're gonna have a devops team or have a devops engineer step one we're gonna rebadge everyone with existing job titles to have the new fancy job titles that reflect it it turns out that's not necessarily sufficient in and of itself not really the spotify model people say like ah we're gonna, we're going to do a Spotify model. We're going to do skills, tribes, you know, and everything is going to be awesome. It's going to be great. You know, a nice cross-functional. The reason that I say it fails almost every single time is because somebody wants to be

in control of the process. And if the process is meant to encourage collaboration and innovation, that person actually becomes a chokehold for it. And it could be somebody that's like, ah, I need to be involved in every single team and listen in on what's happening just so I'm aware of it. But in the end of happening, everybody defers to them. So there is no collaboration. There is no innovation. DevOps, you say, ah, we're going to have a team to do everything so your developers don't need to worry about it. But in the end of happening, it's just still an ops team. do everything so your developers don't need to worry about it but as it's happening it's just still an ops team you still have your silos and that's always the challenge is you actually have to say okay what are the cultural values behind this process you know what is sre what

is devops you know is it series of processes is a series of principles platform maybe you know we have to say like that's why i say platform as a product, because you need to have that product mindset, that culture of product thinking to really build a platform that works because it's all about the user journey. It's not about building a common set of tools. It's the user journey of how a person interacts with their code to get it into a production environment. And so you need to understand how that person sits down at their desk, starts the laptop, logs in, opens their IDE, what they're actually trying to get done.

And once you understand that, then you know your requirements and you build something to fill those things so that they are happy to use it. As opposed to saying, this is our platform and you're going to use it. And they're probably going to say, no. And the next thing you know, they're just doing their own thing on the side. Yeah, the idea of shadow IT has never gone away. It's just on some level, it's the natural expression. I think it's an immune reaction that companies tend to have when process gets in the way. Great, we have an outcome that we need to drive towards. We don't have a choice.

Cloud empowered a lot of that and and also has given tools to help rein it in and as with everything the arms race continues yeah and so i'm going to continue now kind of like to the platform horn so gregor hope he's a solution i was i'm so sorry gregor he has a great book and even a talk called the magical platforms that if somebody is actually curious like understanding you know my platforms are nice they should really watch that talk if you see him at green event or a summit or a summary giving a talk go listen to that and just pick his brain because that's for me i really kind of strongly agree with his approach because that's really how you know as he says like boost innovation is you know we're actually building a platform that really works yeah it's a hard problem but it's also one of those things where you you're trying to focus on at least ideally an outcome or a better situation than

you currently find yourselves in it's hard to turn down things that might very well get you there sooner or faster. But it's like trying to effectively cargo cult the leadership principles from your last employer into your new one. It just doesn't work. I mean, you see more startups from Amazonians who try that and it just goes horribly because without the cultural understanding and the supporting structures, it doesn't work. Exactly. So I've worked with organizations like 4,000 plus people. I've worked for small startups, consulted. And this is why I say almost every single transformation,

it fails the first time because somebody needs to be in control and track things and basically be really, really certain that people are doing it right. And as soon as it blows up in the face, that's when they realize they should actually take a step back. And so even for building out a platform,

you know, doing platform as a product, I always reiterate that you have to really be willing to just invest upfront and not give very much back because you have to figure out the whole user journey and what you're actually building

before you actually build it. I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you? So I used to be on Twitter, but I've actually got off there after it kind of turned a bit toxic and crazy. It feels like that was years ago, but that's beside the point. Precisely.

So I would even just say this feels like a corporate show, but find me on LinkedIn of all places because I will be sharing whatever I find on there, you know, so just look me up on my name, Evelyn Osman, and give me a follow, and I'll probably be screaming into the cloud like you are. And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Thank you, Corey. Evelyn Osman, Engineering Manager at AutoScout24. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast,

please leave a five-star review on your podcast platform of choice. And I will read it once I finish building an internal platform to normalize all of those platforms together into one. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.