Screaming in the Cloud - Building Distributed Cognition into Your Business with Sam Ramji

Episode Date: December 9, 2021

About SamA 25-year veteran of the Silicon Valley and Seattle technology scenes, Sam Ramji led Kubernetes and DevOps product management for Google Cloud, founded the Cloud Foundry foundation, has helped build two multi-billion dollar markets (API Management at Apigee and Enterprise Service Bus at BEA Systems) and redefined Microsoft’s open source and Linux strategy from “extinguish” to “embrace”.He is nerdy about open source, platform economics, middleware, and cloud computing with emphasis on developer experience and enterprise software. He is an advisor to multiple companies including Dell Technologies, Accenture, Observable, Fletch, Orbit, OSS Capital, and the Linux Foundation.Sam received his B.S. in Cognitive Science from UC San Diego, the home of transdisciplinary innovation, in 1994 and is still excited about artificial intelligence, neuroscience, and cognitive psychology.Links:DataStax: https://www.datastax.comSam Ramji Twitter: https://twitter.com/sramjiOpen||Source||Data: https://www.datastax.com/resources/podcast/open-source-dataScreaming in the Cloud Episode 243 with Craig McLuckie: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/innovating-in-the-cloud-with-craig-mcluckie/Screaming in the Cloud Episode 261 with Jason Warner: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/what-github-can-give-to-microsoft-with-jason-warner/

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. This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database

that is not the BindDNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services? These folks have you covered with the go-to managed Redis service for global caching and primary database capabilities, Redis Enterprise. Set up a meeting with a Redis expert during reInvent, and you'll not only learn how you can become a Redis hero, but also have a chance to win some fun and exciting prizes. To learn more

and deploy not only a cache, but a single operational data platform for one Redis experience, visit redis.com slash hero. That's R-E-D-I-S dot com slash hero. And my thanks to my friends at Redis for sponsoring my ridiculous nonsense. Are you building cloud applications with a distributed team? Check out Teleport, an open-source identity-aware access proxy for cloud resources. Teleport provides secure access to anything running somewhere behind NAT, SSH servers, Kubernetes clusters, internal web apps, and databases. Teleport gives engineers superpowers. Get access to everything via single sign-on with multi-factor. List and see all of your SSH servers, Kubernetes clusters, or databases available to you in one place, and get instant access to them

using the tools you already have. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. And best of all, Teleport is open source and a pleasure to use. Download Teleport at goteleport.com. That's goteleport.com. Welcome to Screaming in the Cloud. I'm cloud economist Corey Quinn, and a recurring effort that this show goes to is to showcase people in their best light. Today's guest has done an awful lot. He led Kubernetes and DevOps product management for Google Cloud.

He founded the Cloud Foundry Foundation. He set open source strategy for Microsoft in the noughts. He advises companies including Dell, Accenture, the Linux Foundation. And tying all of that together, it's hard to present a lot of that in a great light because given my own proclivities, that sounds an awful lot like a personal attack. Sam Ramji is the chief strategy officer at Datastacks. Sam, thank you for joining me. And it's weird when your resume starts to read like, oh, I hate all of these things. It's weird, but it's true. And it's the only life I could have lived, apparently, because here I am. Corey, it's a thrill to meet you. I've

been an admirer of your public speaking and public tweeting and your writing for a long time. Well, thank you. The hard part is getting over the voice saying, don't do it, because it turns out that there's no real other side of public shutting up, which is something that I was never good at anyway. So I figured I'd lean into it. And again, I mean that in the sense of where you have been historically in terms of your career, not look what you've done, which is a subtext that I could be accused

of throwing in sometimes. I used to hear that a lot from my parents, actually. Oh yeah, that was my name growing up. But you've done a lot of things and you've transitioned from notable company making significant impact on the industry to the next one, to the next one. And you've been in high-flying roles doing lots of really interesting stuff. What's the common

thread between all those things? I'm an intensely curious person. And the thing that I'm most curious about is distributed cognition. And that might not be obvious from what you see as kind of the lego blocks of my career but i studied cognitive science in college when that was not really something that was super well known so i graduated from uc san diego in 94 doing neuroscience artificial intelligence and psychology and because i just couldn't stop thinking about thinking i was just fascinated with how it worked so then i wanted to build software systems that would help people learn. And then I wanted to build distributed software systems. And then I wanted to learn how to work with people who were thinking about building the distributed software systems. So you end up kind

of going up this curve of like complexity about how do we think? How do we think alone? How do we learn to think? How do we think together? How do we learn to think? How do we think together? And that's the directed path through my software engineering career, into management, into middleware at BEA, into open source at Microsoft, because that's an amazing demonstration of distributed cognition. How, you know, at the time in 2007, I think SourceForge had 100,000 open source projects, which was like mindboggling. Some of them even worked together, but all of them represented these groups of people flung around the world collaborating on something that was just fundamentally useful, that they were curious about. Kind of did the same thing into APIs, because APIs are an even better way to reuse for some cases than having the source code at Apigee

and kept growing up through that into how are we building larger and larger scale thinking systems like Cloud Foundry, which took me into Google and Kubernetes, and then some applications of that in Autodesk and now Datastacks. So I love building companies. I love helping people build companies because I think business is distributed cognition. So the businesses that build distributed systems for me are the most fascinating. You were basically handed a heck of a challenge

as far as, well, help set open source strategy back at Microsoft in the days where that was a punchline. And credit where due, I have to look at Microsoft of today, and it's not a joke. You can have your arguments about them, but again, in those days, a lot of us built our entire personality on hating Microsoft. Some folks never quite evolved beyond that, but it's a new ballgame. And it's very clear that the Microsoft of yesteryear and the Microsoft of today are not completely congruent. What was it like at that point, understanding that as you're working with open source communities, you're doing that from a place of employment with a company that was

widely reviled in the space? It was not lost on me. The irony, of course, was that... Well, thank God, because otherwise the question from you would have been, what do you mean they didn't like us? Which on some levels, like, yeah, that's about the level of awareness I would have expected in that era. But contrary to popular opinion, execs at these companies are not generally oblivious. Yeah, well, if I'd been cleverer as a creative humorist, I would have given you that answer instead of my serious answer. But for some reason, my role in life is always to be the straight guy. I used to have Slashdot as my homepage, right? I loved when I'd see some conspiracy theory about, you know, Bill Gates dressed up as the Borg taking over the world. My first startup actually in 97

was crushed by Microsoft. They copied our product, copied the marketing and bundled it into Office. So I had lots of reasons to dislike Microsoft. But in 2004, I was recruited into their venture capital team, which I couldn't believe. It was really a place that they were like, hey, we could do better at helping startups succeed. So we're going to evangelize their success that they're building with Microsoft technologies to VCs, to enterprises. We'll help you get your first big enterprise deal. I was like, man, if I had this a few years ago, I might not be working. So let's go try to pay it forward. I ended up in open source by accident. I started going to these conferences on software as a service. This is back in 2005 when people

were just starting to light up Silicon Valley Forum with the CEO of Demandware would talk. We'd hear all these different ways of building a new business. And they all kept talking about their tech stack was Linux, Apache, MySQL, and PHP. I went to one eight-hour conference, and Microsoft technologies were mentioned for about 12 seconds in two separate chunks. So six seconds each, like, oh, and also we really like Microsoft SQL Server for our data layer. Oh, Microsoft SQL Server was fantastic. And I know that's a weird thing for people to hear me say, just because I've been renowned recently for using Route 53 as the primary data store for everything that I can. But there was nothing quite like that as far as having multiple write nodes, being able to handle sharding effectively. It was expensive and you would take a bath on the price income audit time,

but people were not rolling it out, not aware of those things. There's a trade-off that they were making. Oracle has a similar story with databases. It's, yeah, people love to talk smack about Oracle and its business practices for a variety of excellent reasons, at least in the database space that hasn't quite made it to cloud yet, knock on wood, but people weren't deploying it because they thought Oracle was warm and cuddly as a vendor. They did it because they can tolerate the rest of it because their stuff works. It's so well said. And people don't give them the credit that's due. Like when they built HyperGrowth in their business, like they had a great product. It really worked. They made it expensive and they made a lot of money on it. And I think that was why, you know, you saw MySQL so successful and why if you were looking for a SPAC that worked that you could talk through

through an open driver like ODBC or JDBC or whatever, you could swap to Microsoft SQL Server. But I walked out of that and came back to the VC team and said, Microsoft has a huge problem. This is a massive market wave that's coming. We're not doing anything in it. They use a little bit of SQL Server, but there's nothing else in your tech stack that they want or like or can afford because they don't know if their businesses are going to succeed or not. And they're going to go out of business trying to figure out how much licensing costs they would pay to you in order to consider using your software. They can't even start there. They have to start with open source. So if you're going to deal with SaaS, you're going to have to have open source and get it right. So I worked with some folks in the industry,

wrote a 10-page paper, sent it up to Bill Gates for Think Week, didn't hear much back, brought a new strategy to the head of developer and platform evangelism, Sanjay Parthasarathy, who suggested that the idea of discounting software to zero for startups with the hope that they would end up doing really well with it in the future as a software as a service company was dead on arrival.

Dumb idea, bring it back. That actually became BizSpark, the most popular program in Microsoft partner history. And then about three months later, I got a call from this guy, Bill Hilf. And he said, hey, this is Bill Hilf. I do open source at Microsoft. I work with Bill Gates. He sent me your paper. I really like it. Would you consider coming up and having a conversation with me? Because I want you to think about running open source technology strategy for the company. And at this time, like 33 or 34, and I'm like, who me? You got to be joking. And he goes, oh, and also you'll be responsible for doing quarterly deep technical briefings with Bill Gates. I was like, you must

be kidding. And so of course I had to check it out. One thing led to another. And all of a sudden with not a lot of history in the open source community, but coming in it with a strategist's eye and with the technologist's eye saying, this is a problem we've got to solve. How do we get after this pragmatically? And the rest is history, as they say. I have to say that you are the chief strategy officer at DataStax. And I pull up your website quickly here. And a lot of what I tell earlier stage companies is effectively more or less what you have already done. You haven't named yourself after the open source project that underlies the bones of what you have built. So you're not going to wind up in the same glorious challenges that, for example, Elastic or MongoDB have in some ways. You have a pricing page

that speaks both to the reality of, it's two in the morning, I'm trying to get something up and running, and I want you the hell out of my way. Just give me something that I can work with, with a reasonable free tier, and don't make me talk to a salesperson. But also, your enterprise tier is click here to talk to a human being, which is speaking enterprise slash procurement slash, oh, there will be contract negotiation on these things. It's being able to serve different ends of your market, depending upon who it is that encounters you without being off-putting to any of those. And it's deceptively challenging for companies to pull off or get right. So clearly you've learned lessons by doing this.

That was the big problem with Microsoft for the longest time. It's if I want to use some Microsoft stuff, once you were able to download things from the internet, it changed slightly. But even then it was one of those, what exactly am I committing to here as far as signing up for this?

And am I giving them audit rights into my environment? Is the BSA about to come out of nowhere and hit me with a surprise audit and find out that various folks throughout the company have installed this somewhere and now I owe more than the company's worth? That was always the haunting fear that companies had back then. These days, I like the approach that companies are taking with the SaaS offering. You pay for usage.

On some level, I'd prefer it slightly differently in a pay-per-seat model because at least then you can predict the pricing. But no one is getting surprise submarine with this type of thing on an audit basis, and then they owe damages and payment and arrears, and someone has them over a barrel. It's just, oh, the bill this month was higher than we expected. I like that model. I think the industry does, too. I think that's super well said. As I used to joke at BEA Systems, nothing says I love you to a customer like an audit. That's kind of a one-time use strategy. If you're going to go audit licenses to get your Windows versus Linux, you would have a structure where sales reps were really compensated to sell as much as possible up front so they could get the best possible commission on what might be used perpetually.

But then if you think about the boxes in a curve, if you do that calculus approximation of a smooth curve, a perpetual software license is a huge box, and there's an enormous amount of waste in there, and customers figure it out. So as soon as you can go to a pay per user, pay as you go, you start to smooth that curve, and now what you get is what you deserve, right, as opposed to getting filled with way more cost than you expect. So I think this model is really super well understood now, kind of the long run, the high point of open source meets cloud, meets software as a service. You look at what companies like MongoDB and Confluent and Elastic and Databricks are doing, and they've really established a very good path through the jungle of how to succeed as a software company. So it's still difficult to implement, but there are really world-class guides right now. Moving beyond where Microsoft was back in the

noughts, you were then hired as a VP over at Google. And in that era, the fact that you were hired as a VP at Google is fascinating. They preferred to grow those internally, generally from engineering. So first question, when you were being hired as a VP in the product org, did they make you solve algorithms on a whiteboard to get there? They did not. I did have somewhat of an advantage because they'd seen me working pretty closely as the CEO of the Cloud Foundry Foundation. I'd worked closely with Craig McLuckie, who notably brought Kubernetes to the world along with Joe Bita and with Eric Brewer and a number of others. And he was my champion at

Google. He was like, look, we need him doing Kubernetes. Let's bring Sam in to do that. So that was helpful. I also wrote a 2,000-word strategy document just to get some thoughts out of my head. And I said, hey, if you like this, great. If you don't, throw it away. So the interviews were actually very much not solving problems on a whiteboard. They were super collaborative, really excellent conversations. It was slow. Let's be clear. Craig McLuckie's most notable achievement was being a guest on this podcast back in

episode 243. But I'll say that this is a close second. You're not wrong. And of course, now with Heptio and their acquisition by VMware. Okay, making money beyond the wildest dreams of avarice. That's all well and good, but an invite to this podcast, that's where it's at. Well, he should really come on again so he can double down and beat everybody. That can be his landmark achievement, a two-timer on Screaming in Cloud.

You were at Google, you were at Microsoft. These are the big titans of their era in some respect, not to imply that there has been, they're bigger than ever, but it's also a more crowded field in some ways. I guess completing the trifecta would be Amazon, but you've had the good judgment never to work there directly. Of course, now they're clearly in your market. You're at Datastacks, which is, which is among other things, built on Apache Cassandra, and they launched their own Cassandra service named Keyspaces because no one really knows why or how they name things. And of course, looking under the hood at the pricing model,

it's pretty clear that it really is just DynamoDB wearing some Groucho Marx glasses with a slight upcharge for API level compatibility. Great. So I don't see it a lot in the real world and that's fine. But I'm curious as to your take on looking at all three of those companies at different eras.

There was always the threat in the open source world that they are going to commit and crush you. You said earlier that Microsoft crushed your first startup. Google is an interesting competitor in some respects. People don't really have that concern about them. And your job as a chief strategy officer at Amazon is taken over by a post-it note that simply says yes on it, because there's nothing they're not going to do or try and experiment with. So from your perspective, if you look at the Titans, who is it that you see as the largest competitive threat these days, if that's even a thing? If you think about Sun Tzu and the art of war, right, a lot of strategy comes from what we've learned from military environments.

Fighting a symmetric war, right, using the same weapons in the same army against a symmetric opponent, but having one one-hundredth of the personnel and one one-hundredth of the money is not a good plan. We're going to lose money. We could be out-competed. We'll make it up in volume. Oh, by the way, we're also slower than they are. So, you know, trying to come after AWS or Microsoft or Google as an independent software company, pound for pound, face-to-face, right, full frontal assault is psychotic. What you have to do, I think, at this point is to understand that these are each companies that are much like we thought about Linux and, you know, Macintosh and Windows as operating systems. They're now the operating systems of the planet. So that creates some economies of scale, some efficiencies for them and for us.

Look at how cheap object storage is now, right? So there's never been a better time in human history to create a database company because we can take the storage out of the database and hand it over to Amazon or Google or Microsoft to handle it with 13 nines of durability on a constantly falling cost basis. So that's super interesting. So you have to prosecute the structure of the world as it is based on where the giants are and where they'll be in the future. Then you have to turn around and say, what can they never sell? So Amazon can never sell something that is standalone, right? They're a parts factory. And if you buy into the Amazon first strategy of cloud computing, which we did at Autodesk when I was VP of cloud platform there, everything is a primitive that works inside Amazon,

but they're not going to build things that don't work outside of the Amazon primitives. So your company has to be built on the idea that there's a set of people who value something that is purpose-built for a particular use case that you can start to broaden out. It's really helpful if they would like it to be something that can help them escape a really valuable asset away from the center of gravity that is a cloud. And that's why data is super interesting. Nobody wakes up in the morning and says, boy, I had such a great conversation with Oracle over the last 20 years beating me up on licensing. Let me go find a cloud vendor and dump all of my data in that so they can beat me up for the next 20 years. Nobody says that. There's the idea of data portability that drives decision-making, which makes people,

of course, feel better about not actually moving it anywhere. But the fact that they're not locked in strategically in a way that requires a full software re-architecture and data model rewrite is compelling. I'm a big believer in convincing people to make decisions that look a lot like that. Right. And so that's the key, right? So when I was at Autodesk, we went from our $100 million committed spend with 19% discount on the big three services to like, we started to realize when we're going to burn through that, we were spending 60 million or so a year, 20% annual growth as the cloud part of the business group. I thought, okay, let's renegotiate. Let's go and do a $250 million deal. I'm sure they'll give us a much better discount than 19%. Short story is they came back and said, you know, we're going to take you from an already generous 19% to an outstanding 22%.

We thought, wait a minute, we already talked to Intuit. They're getting a 40% discount on a $400 million spend. So math is hard, but 40% minus 22% is 18% times $250 million is a lot of money. So we thought, what is going on here? And we realized we just had no credible threat of leaving and Int Intuit did, because they had built a cross-cloud capable architecture, and we had not. So now, stepping back into the world that we're living in in 2021, if you're an independent software company, especially if you have the unreasonable advantage of being an open-source software company, you have got to be doing your customers good by giving them cross-cloud capability. It could be simply

like the Amdahl coffee cup that Amdahl reps used to put as landmines for the IBM reps later. I can tell you that story if you want. Even if it's only a way to save money for your customer by using your software, when it gets up to tens and hundreds of millions of dollars, that's a really big deal. But they also know that data is super important. So the option value of being able to move, if they have to, that they have to be able to pull that stick instead of saying, nice doggy, we have to be on their side, right? So there's almost a detente that we have to create now as cloud vendors, working in a world that's invented and operated by the giants. This episode is sponsored by our friends at Oracle HeatWave, a new high-performance query accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel.

While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work while also performing 1,100 times faster than Amazon Aurora and two and a half times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. When we look across the, I guess, the ecosystem as it's currently unfolding, a recurring challenge that I have to the existing incumbent cloud providers is they're great at offering the bricks that you can use to build things.

But if I'm starting a company today, I'm not going to look at building it myself out of, ooh, I'm going to take a bunch of EC2 instances or Lambda functions or Popsicles and String and turn it into this thing. I'm going to want to tie together things that are way higher level. In my own case now, I wind up paying for Retool, which is effectively, yeah, it runs on some containers somewhere, presumably, I think in Azure, but don't quote me on that. And that's great. Could I build my own thing like that? Absolutely not. I would rather pay someone to tie it together. Same story.

Instead of building my own CRM by running some open source software on an EC2 instance, I wind up paying for Salesforce or Pipedrive or something in that space, and so on and so forth. And a lot of these companies that I'm doing business with are themselves running on top of AWS. But for web hosting, for example, if I look at the reference architecture for a WordPress site, AWS's diagram looks like a punchline. It is incredibly overcomplicated. And I say this as someone who ran large WordPress installations at MediaTemple many years ago. Now I have the good sense to pay WP Engine. And on a monthly basis, I give them money and they make the website

work. Sure, under the hood, it's running on top of GCP or AWS somewhere, but I don't have to think about it. I don't have to build this stuff together and think about the backups and the failover strategy and the rest. The website just works. And that is increasingly the direction that business is going. Things commoditize over time. And AWS in particular has done a terrible job, in my experience, of differentiating what it is they're doing in the language that their customers speak. They're great at selling things to existing infrastructure engineers, but folks who are building something from scratch aren't usually in that cohort. It's a longer story with time. And while we're great at being able to sell

EC2 instances by the gallon, great, are you capable of going to a small doctor's office somewhere in the American Midwest and offering them an end-to-end solution for managing patient data? Of course not. You can offer them a bunch of things they can tie together to something that'll suffice if they all happen to be software engineers, but that's not the opportunity. So instead, other companies are building those solutions on top of AWS, capturing the margin. And if there's one thing guaranteed to keep Amazon execs awake at

night, it's the idea of someone who isn't them making money somehow, somewhere. So I know that's got to rankle them, but they do not speak that language at all. Longer term, I only see that as a more and more significant crutch. A long enough time frame here, we're talking about them becoming the CenturyLinks of the world, the tier one backbone provider that everyone uses, but no one really thinks about because they're not a household name. That is a really thoughtful perspective. I think the diseconomies of scale that you're pointing to start to creep in, right? Because when you have to sell compute units by the gallon, right, you can't care if it's a gallon of milk or a gallon of oil or, you know, a gallon of poison, right? You just have to keep moving it through. So the shift that I think they're going to end up having to make pragmatically, and you start to see some signs of it,

like, you know, they hired but could not retain Matt Acey. He did an amazing job of bringing them to some pragmatic realization that they need to partner with open source. But more broadly, when I think about Microsoft in the 2000s, as they were starting to learn their open source lessons, we were also being able to pull on Microsoft's deep competency and partners. So most people didn't do the math on this. I was part of the field governance council. So I understood exactly how the Microsoft business worked to the level that I was capable. When they had $65 billion in revenue, they produced $24 billion in profit through an ecosystem that generated $450 billion in revenue. So for every dollar Microsoft made, it was $8 to partners. how they were able to get into doctor's offices in the Midwest and kind of fit the curve that you're describing of all of those long-tail opportunities that require so much care and that are complex to prosecute, they solved for their diseconomies of scale

by having 1.2 million partner companies. So will Amazon figure that out? And will they hire enough people who've done this before from Microsoft to become world-class and partnering. That's kind of an exercise left to the reader, right? Where would that go over time? But I don't see another better mathematical model for dealing with the diseconomies of scale you have when you're one of the very largest providers on the planet. The hardest problem is, as I look at this, is at some point you hit a point of scale where smaller things look a lot less interesting. I get that all the time when people say, oh, you fix AWS bills. Aren't you missing out by not targeting Google bills and Azure bills as well? And it's, yeah, I'm not VC-backed. It turns out that if I limit the customer base that I can effectively service to

only AWS customers, yeah, it turns out I'm not going to starve anytime soon. Who knew? I don't need to conquer the world. And that feels increasingly antiquated, at least going by the stories everyone loves to tell. Yeah, it's interesting to see how cloud makes strange bedfellows, right? We started seeing this in like 2014, 2015. Weird partnerships that you're like, there's no way this would happen. But the cloud economics, which go back to utilization rather than what it used to be, which was software lock-in, just changed who people were willing to hang out with. And now you see companies like Databricks going, we do an amazing amount of business effectively competing with Amazon selling Spark

services on top of predominantly Amazon infrastructure, and everybody seems happy with it. So there's some hint of a new sensibility of what the future of partnering will be. We used to call it coopetition a long time ago, which is kind of a terrible word, but at least it shows that there's some nuance in you can't compete with everybody because it's just too hard. I wish there were better ways of articulating these things because it seems to me all the outside world, you have companies like Amazon and Microsoft and Google who go and build out partner networks because they need that external accessibility into various customer profiles that they can't speak to super well themselves. But they're also coming out with

things that wind up competing directly or indirectly with all of those partners at the same time. And I don't get it. I wish that there were smarter ways to do it. It is hard to even talk about it, right? One of the things that I think we've learned from philosophy is we don't have a word for it. We can't be intelligent about it. So there's missing semantics here for being able to describe the complexity of where are you partnering? Where are you competing? Where are you differentiating in an ecosystem, which is moving and changing? I tend to look at the tools of game theory for this, which is to look at things as either non-zero sum games or zero sum games. And if it's a non-zero sum game,

which I think are the most interesting ones, can you make it a positive-sum game? And who can you play positive-sum games with? An organization as big as Amazon or as big as Microsoft or even as big as Google isn't ever completely coherent with itself. So thinking about this as an independent software company, it doesn't matter if part of one of these hyperscalers has a part of their business that competes with your entire business. Because your business probably drives utilization of a completely different resource in their company that you can partner within them against them effectively. For example, Cassandra is an amazingly powerful but demanding workload on Kubernetes. So there's a lot of Cassandra on EKS. You grow a lot of workload and the EKS business does super well. Does that prevent us from working with Amazon because they have Dynamo

or because they have Keyspaces? Absolutely not. So this is when those companies get so big that they are almost their own forest of complexity. You can kind of get in, hang out, do well, and pretty much never see the competitive product unless you're explicitly looking for it, which I think is a huge danger for us as independent software companies. And I would say this to anybody doing strategy for an organization like this, which is don't obsess over the tiny part of their business that competes with yours and do not pay attention to any of the marketing that they put out that looks competitive with what you have. Because if you can't figure out how to make a better product and sell it better to your customers as a single-purpose corporation, you have bigger problems. I want to change gears slightly to something that's probably a fair bit more insulting, but that's okay.

We're going to roll with it. That seems to be the theme of this episode. You have been, in effect, a CIO a number of times at different companies. And if we take a look at the typical CIO tenure industry-wide, it's not long. It approaches the territory from an executive perspective of be sure not to buy green bananas. You might not be here by the time they ripen.

And I'm wondering what it is that drives that and how you make a mark in a relatively short timeframe when you're providing inputs and deciding on strategy, and those decisions may not bear fruit for years. CIO used to, we used to say it stood for career is over because the tenure is so short. I think there's a couple of reasons why it's so short. And I think there's a way I believe you can have impact in a short amount of time. I think the reason that it's been short is because people aren't sure what they want the CIO role to be. Do they want it to be a glorified finance

person who's got a lot of data processing experience, but now really has got maybe even an MBA in finance, but is not focusing on value creation? Do they want it to be somebody who's all singing, all dancing, chief data officer with a CTO background who did something amazing and solved a really hard problem. The definition of success is difficult. Often CIOs now also have security under them, which is literally a job I would never, ever want to have. Do security for a public corporation? Good Lord, that's a way to lose most of your life. You're the only executive other than CEO that the board wants to hear from. You don't sleep. You wait in those scenarios. And oh yeah, people joke about ablative CISOs in those scenarios. Yeah, if your solar winds, you try and get an ablative intern instead,

but those don't work as well. It's a matter of waiting for an inevitability. One of the things I think is misunderstood about management broadly is that you are delegating work, but not the responsibility. The responsibility rests with you. So when companies have these statements blaming some third-party contractor, it's, no, no, no, I'm dealing with you. You were the one that gave my data to some sketchy randos. It is your responsibility that that data has now been compromised. And people don't want to hear that, but it's true. I think that's absolutely right. So you have this high risk, medium reward, very fungible job definition, right? If you ask all of the CIOs peers what their job is, they'll probably all tell you something different that represents their wishlist.

The thing that I learned at Autodesk, I was only there for 15 months, but we established a fundamental transformation of the work of how cloud platforms done at the company that's still in place a couple of years later, you have to realize that you're a change agent, right? You're actually being hired to bring in the bulk of all the different biases and experiences you have to solve a problem that is not working, right? So when I got to Autodesk, they didn't even know what their uptime was. It took three months to teach the team how to measure the uptime. It turned out the uptime was 97.7% for the cloud for the world's largest engineering software company. That is 200 hours a year of unplanned downtime, right? That is not good. So a complete overhaul was needed.

Understanding that as a change agent, your half-life is 12 to 18 months. You have to measure success, not on tenure, but on your ability to take good care of the patient, right? It's going to be a lot of pain. You're going to work super hard. You're going to have to build trust with everyone. And then people are still going to hate you at the end as something you just have to kind of take on. As a friend of mine, Jason Warner joined Redpoint Ventures recently. He said this when he was the CTO of GitHub. No one is a villain in their own story. So you realize going into a big organization, people are going to make you a villain, but you still have to do incredibly thoughtful, careful work that's going to take care of

them for a long time to come. And those are the kinds of CIOs that I can relate to very well. Jason's great. You're name-dropping all the guests we've had. My God, keep going. It's a hard thing to rationalize and wrap heads around. It's one of those areas where you will not be measured during your tenure in the role in some respects. And of course, it leads to the cynical perspective as well, where, well, someone's not going to be here long. And if they say, yeah,

we're just going to keep being stewards of the change that's already underway, well, that doesn't look great. So quick, time to do a cloud migration or a cloud repatriation or time to roll something else out. Bit of a different story. One of the biggest challenges is how do you get the hearts and the minds of the people who are in the organization when they are no fools and their expectation is like, hey, this company has been around for decades and we go through cloud leaders or CIOs like Wimpy goes through hamburgers, they could just cloud wash, right? Or change wash all their language. They could use the new language to describe the old thing because all they have to do is get through the performance review and outweigh you. So there's always going to be a level of defection because it's hard to change.

It's hard to think about new things. So the most important thing is how do you get into people's hearts and minds and enable them to believe that the best thing they could do for their career is to come along with the change. And I think that was what we ended up getting right in the Autodesk Cloud transformation. And that requires endless optimism and there's no room for cynicism because the cynicism is going to creep in around the edges. So what I found in the job is you just have to get up every morning and believe everything is possible and transmit that belief to everybody. So if it seems naive or ingenuous, I think that doesn't matter as long as you can move people's hearts in each conversation towards like, oh, this person cares about me. They care about a good outcome for me. I should listen a little bit more

and maybe make a 1% change in what I'm doing. Because 1% compounded daily for a year, you can actually get something done in the lifetime of a CIO. And I think that's probably a great place to leave it. If people want to learn more about what you're up to, how you think about these things, how you view the world,

where can they find you? You can find me on Twitter. I'm at SRamji, S-R-A-M-J-I. And I have a podcast that I host called Open Source Data, where I invite innovators, data nerds, computational networking nerds to hang out and explain to me, a software programmer, what is the big world of open source data all about, what's happening with machine learning, and what would it be like if you could put data in a container just like you could put code in a container, and how might the world change?

So that's Open Source Data Podcast. And we'll, of course, include links to that in the show notes. Thanks so much for your time. I appreciate it. Corey, it's been a privilege. Thank you so much for having me. Likewise. Sam Ramji, Chief Strategy Officer at DataStax. 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, along with a comment telling me exactly which item in Sam's background that I made fun of is the place that you work at. 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. This has been a HumblePod production. Stay humble.