Becoming a RedMonk with Stephen O’Grady

Stephen O'Grady is a Principal Analyst and co-founder of RedMonk, the open source industry analyst firm. He focuses on infrastructure software such as programming languages, operating systems and databases, as well as covering horizontal industry trends such as open source and cloud computing.

 

Before setting up RedMonk, Stephen worked as an analyst at Illuminata by drawing on his real world expertise in architecting and developing applications for leading systems integrators. Prior to joining Illuminata, Stephen served in various senior capacities with large systems integration firms like Keane and boutique consultancies like Blue Hammock.

 

Regularly cited in publications such as the New York Times, BusinessWeek, the Boston Globe, and the Wall Street Journal, and a popular speaker and moderator on the conference circuit, Stephen's advice and opinion is well respected throughout the industry.

Transcript


Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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.

Corey: This episode is brought to you by DigitalOcean, the cloud provider that makes it easy for startups to deploy and scale modern web applications with, and this is important to me, no billing surprises. With simple, predictable pricing that’s flat across 12 global data center regions and UX developers around the world love, you can control your cloud infrastructure costs and have more time for your team to focus on growing your business. See what businesses are building on DigitalOcean and get started for free at do.co/screaming. That’s D-O-Dot-C-O-slash-screaming and my thanks to DigitalOcean for their continuing support of this ridiculous podcast.

Corey: This episode is brought to you by Spot.io, the continuous cloud cost optimization platform, saving businesses millions of dollars each year on their cloud bills used by some of the world's largest enterprises and fastest growing startups like Intel and Samsung. Those are enterprises and duo lingo.  That's a startup. Spot.io delivers the optimal balance of cost and performance by leveraging spot instances, reserve capacity, and on demand. Give your workloads the infrastructure they deserve. Always available, always scalable, and always at the lowest possible cost. Visit Spot.io to learn more.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Steve O'Grady, Principal analyst and co-founder of RedMonk. Welcome to the show, Steve.

Steve: My pleasure.

Corey: So, let's start at the beginning. What exactly is a RedMonk?

Steve: [laughs] It's an excellent question. So, a RedMonk is somebody who, in my case obviously, works for an analyst firm. In this particular instance, RedMonk, the analyst firm. We're a small firm, we're developer-focused. We have been doing this for much longer than James and I would care to admit. So, yeah, I think, like a lot of analyst firms, we do research analysis, and we look at trends and what's being used, what's not, why, all sorts of fun things, we just take a little bit different, yeah, like I said, lens or angle to the question, in the sense that we are big believers in the practitioner. So, yeah, that's what RedMonk is.

Corey: So, let's back up a second because Lord knows I didn't know the answer to this. What's an analyst firm?

Steve: Yeah, that's a really good question. And it is one that, frankly, if you asked my parents or probably any of the parents of any of our other analysts, none of the parents would be able to give you a clean answer. So, you are in good company if you don't know the answer to that. The short answer is that, so we research. That's our primary work activity. And that means we talk to all sorts of people. We talk to developers, we talk to engineers, designers, operators, admins, take your pick. DBAs, and an on and on and on. We perform quantitative research. So, we'll go out and look at, oh I don’t know, GitHub, Stack Overflow. Anything we think is going to give us a sense of quantitative trends from a developer perspective. And then, we talk to companies, lots and lots and lots of companies. So, the nut of it is that we talk to—so we have all these conversations, we do all this research, primary and otherwise, and we synthesize that. We look at it, sit from a distance. And we make judgments in terms of, okay, we think this technology is going to go up and we think this technology is going to go down. Here's why. And perhaps more importantly from a commercial standpoint, companies and businesses alike then want to understand. Okay, so given this trend, how do I apply this to my business, right? So, an example of this would be I wrote a piece last month, I think—at least a couple weeks ago—talking about Amazon, and how one might go about competing with Amazon. That piece is itself a product of a lot of analysis on our part, looking at conversations and also having a long history in this market looking at, okay, what has worked and what hasn't, and why. So, you put the history together; you put the research together; you come out with this piece that says, okay, if you’re going to try to compete with Amazon, which is obviously very difficult, here's one way you might do that. And so, a lot of people read that and we're fortunate to have this to be pretty widely disseminated. And then, basically, companies will come back to us and say, “Okay, well, what does that mean for my business?” And our job is to answer that as best we can. So, yeah, I mean, we do lots of different things for lots of different companies, and it depends on what people need. Sometimes it’s, tell me why my messaging sucks. Sometimes it’s, how do I reach developers? So, there's lots of different questions we answer, but that's probably the shortest version I can give you.

Corey: [laughs] It's fun, in that I've inadvertently been dragged into analyst events and a few analyst engagements so far, which is fun because I have no earthly idea what an analyst actually does, but in my expression of it, it always seems that oh, the sarcastic snarky things you say to people in public that you have to apologize for later. Well, can you come say that to us about what we're working on? Which was interesting. It was a source of insight to some extent, and I didn't realize this was actually an entire profession. And surprise, come to find out that it, sort of, is.

Steve: Yeah, not everybody can quite bring the snark the way you can, but for sure, I mean, one of the things that all analysts, to some degree, are paid to do, at least by—well, I should say there are companies that basically want to pay analysts to come in and say that they're the greatest thing in the world. And if anybody listening to us is an analyst that does that, more power to you. That's not what we do. We don't believe in that. So, we're there to talk about are companies that genuinely want to improve, want to get better, and want to know, all right, where are my blind spots? What are the things I'm not thinking of? Because however smart any one of these companies are, the simple fact is that we have access to many, many more companies than they do. Because—look, whether you're selling technology, whether you're buying technology, most of your competitors probably aren't going to talk to you, right? They do talk to us. So, we're in a, we're in a very unique position to be able to have a lot of conversations that very few companies are in a position to have on their own. So, we can pair that and add that to all these performance research that we do. And, hopefully, in any given conversation tell you something you didn't know before, we showed up.

Corey: Insight, it's one of those valuable things that people tend to, at least in my experience, value almost exactly as much as they pay for it. Free advice, turns out you can get that on the internet and most people don't tend to play those games. Whereas, when you have someone who sits there—especially in your case, where you provide a quantitative aspect to something that is otherwise a qualitative discussion—it starts to be a much different story. I made fun of the whole Gartner Magic Quadrant dance for many years, back when I was an engineer, and then I started doing more, as I always say, business-level work, speaking with decision-makers at levels that went beyond just code, and I suddenly saw the value of it where I never had before. Which brings us to a topic I've been meaning to pick your brain on in a scenario when you couldn't possibly say no, the book that you wrote circa 2012 if memory serves—

Steve: Yeah. Was it 2012? I think it's 2013. I don't even know at this point.

Corey: My awareness of the passing of time continues to get fuzzier.

Steve: Yeah, I hear you. Yeah. So, what do you want to know? What do you want to know about The New Kingmakers?

Corey: Yes, The New Kingmakers was a relatively short read that talked about developers as being the determining factor whether or not any particular vendor would succeed or fail at driving adoption. Is that a reasonable tweet-size synopsis? Or have I missed a whole bunch of salient point?

Steve: Well, so I think the—so you mentioned the length. The length is interesting because that is—I joked about this on Twitter at one point, if anybody is suffering from a lack of humility, the simplest solution for that is to write a book, and then to go read the reviews of your book, particularly the one- and two-star reviews, because it is one of the major complaints and criticisms of that book was that it's too short. Because I don’t remember what it was, I think it's, I want to say it's, like, 18, 19,000 words which is, say half the length, maybe a little more than a third the length of regular business text. So, the funny thing is, I did that intentionally. It's not for lack of case studies. It's not for lack of evidence, it was more, I had read a book by Erik Brynjolfsson and Andrew McAfee. And basically, they did the same thing in their book. And it was 75, 80 pages, I want to say. And it's I realized after reading it, I was like, okay, look, you can communicate about a topic, introduce it, provide the evidence, provide recommendations in a relatively limited span of time, because essentially, from my perspective, I didn't have time to spend one hundred fifty, three hundred, four hundred pages, whatever it might be on that subject for a book. I did have time to invest, all right, 75 pages, I can knock that out. So, yeah, I took the essentially same approach with The New Kingmakers and thought, all right, there's probably a whole bunch of people who are not willing to invest three, four or five hundred pages in concept of developers, but if I keep it shorter maybe they'll go out and read it. And for the people that worked for, it worked like a champ. People were like, “Oh, this is great you can, in many cases, absorb it one sitting.” And then, for the people who it doesn't work for them, well, they're the people who are leaving one or two-star reviews. More power to them.

Corey: Never read the reviews, never read the comments.

Steve: Right. Now, some of the reviews are good and they'll provide you with feedback. I could say that though, as a white male. Much easier for me to do that, than if you were a person of color, or women or, or something like that. So, yeah, you're going to get to own and acknowledge your privilege where it exists. Anyway, back the point. One of the really funny things about that book for me was that I had a lot of conversations with engineers after it came out, and most of the conversations went something like, hey, it was really good, it was interesting, and there are definitely some use cases in here that I hadn't heard of, or some facts and some figures and so on, but I mostly knew this. This isn't anything super new to me. And my reply to all these engineers was, it's not supposed to be, this is not for you. Basically, the purpose of the book, in a nutshell, was to the importance of developers in it, as we term it, the new kingmakers, had been apparent to us for quite some time. And I kept having the same conversation over and over and over with senior executives at vendors, enterprises, and everything in between, and thought, “All right, I can keep having this one on one level conversation, or I can package this up and potentially recruit developers into upselling the book, one for their own benefit and two, so I don't have to keep having the same conversation over and over.” So, basically, the object was to take this, put it in developers hand, and be able to put them in a position where they can hand it to their boss and say look, this is only, like, 70, 80 pages, depending on the printing, whatever it is, you could read this quickly, and then you'll realize why these teams are important. And in many cases, it was a success. There are certain folks, as I said, who are less than thrilled with one or more aspects of the book, but I think for the folks that, particularly for the engineers whose bosses have read it, I think, hopefully, it made a difference, just in the way that they're valued within an organization, which is, look, if I could accomplish nothing else in our role at RedMonk, that's a good thing.

Corey: One thing that I found refreshing about it is the length, where there are too many business books that I've read over the course of my career, where it seems that, yeah, this really is about an 80-page book that is struggling to get out of the 300-page book that the publisher made them write. Where you wind up with this tremendous amount of fluff that belabors the same point, all the case studies, all the rest, and yeah, I just needed that core of it.

Steve: That's right. Yeah.

Corey: Yeah, the overall thesis of the book where developer experience was driving acquisition decisions, as opposed to terrible software that was aimed at the buyer, who was very far removed from the person implementing it, that rising tension and that rising approach has been proven to be correct, in an awful lot of spaces. What I find challenging from a business perspective, given that what I tend to do is purely advisory around the AWS bill, is that engineers, in my experience, for what I do, are terrible customers across the board.

Steve: [laughs] Yeah, yeah. So, like I said, we definitely had some interesting and some challenging conversations with engineers afterwards, either of the type that I noted, which is, hey, I knew this already. Or people who wanted to bike shed it, and basically say, “Hey, here's this one nit in this one area and let me tell you all the reasons that this is wrong.” So, that's fine, right? That comes with the territory. That's not that big a deal. I think, like I said, the difference, I think, at least in my experience, as I have—well, literally as I directly experienced, in the wake of the book is, essentially, that even the people who wanted to nitpick it, they recognized that it was in their best interest to distribute this. Because it's difficult for us to remember now, because we exist in a world where developers are very highly prized, but certainly in the years running up to the publication, and even the years directly afterwards—we're going back again to, whenever it was, 2012, 2012 certainly when it was in the drafting forum, either published in 2012 or 2013, I can't remember—the importance of developers within organizations was certainly not the centrally agreed-on valuation that it is today. So, what we're trying to do is put developers in a position where they could—help them make a business case to their boss, or their boss's boss, or their boss's boss's boss or, in a couple of cases, we had conversations with developers who had said—where was it? I think it was a Red Hat summit—there's a gentleman by the name of Kieran Broadfoot, who is a senior executive over at Barclays, and he gave a talk at the summit and whipped out the book and was like, “Hey, this is great, and we issue this to our engineers.” Very, very nice guy. I had the opportunity to chat with them afterwards. The interesting thing to me is that I later had conversations with engineers, whose CEO, VP of engineering, pika, in the CIO, pika senior leadership term, was at that talk, and their senior executives went out and bought the book because, hey, somebody on stage at Red Hat recommended it and came to them and said, “Hey, you guys are really important. What can I do to help?” so I think it is certainly true that engineers are not always your best customer, but I think when you're in a position where you are going to directly advance their interests, and where your interests are very much mutually aligned, then your life is, I want to say, much easier.

Corey: This episode is sponsored in part by ChaosSearch. Now their name isn’t in all caps, so they’re definitely worth talking to. What is ChaosSearch? A scalable log analysis service that lets you add new workloads in minutes, not days or weeks. Click. Boom. Done. ChaosSearch is for you if you’re trying to get a handle on processing multiple terabytes, or more, of log and event data per day, at a disruptive price. One more thing, for those of you that have been down this path of disappointment before, ChaosSearch is a fully managed solution that isn’t playing marketing games when they say “fully managed.” The data lives within your S3 buckets, and that’s really all you have to care about. No managing of servers, but also no data movement. Check them out at chaossearch.io and tell them Corey sent you. Watch for the wince when you say my name. That’s chaossearch.io.

Corey: To be very clear, one of the challenges I've had with engineers as customers is—I should probably qualify that before I wind up getting letters—has been that engineers are always very passionate about what it is that I'm focusing on. I will sit down and have a 90-minute conversation easily with engineering types. And they will talk all about how I do what I do, the different areas I can wind up addressing. And at the end of it, it's almost like I'm talking with Hacker News, surprise, surprise. Well, that doesn't sound hard. I could build that in a weekend. Cool, great. But before you do that, and go tilt at that windmill, can I can maybe talk to your boss? And from there, that conversation generally tends to pivot into introductions, because it turns out if you dig a little bit beneath that surface layer as well, engineers are very challenging to win over, and by the time that you wind up, effectively getting them in your corner, it turns out their signing authority caps out somewhere around 50 bucks a month. So, they're not in a position to be your buyer. At best they can be your champion.

Steve: Yeah. Yeah, I think it helps when, first of all, I was helped out because the product was initially sponsored by New Relic, later sponsored by—I can’t remember who the second one was—PayPal. These are all through O'Reilly. So, developers didn't have to pay anything. They could just go buy it. And in those cases, if I remember right, I think it was a PDF. So, they could just take this free PDF that they’d been given and send it to their boss. So, in these cases, I don't have any issues with, you know, certainly selling the book. If you can't sell a $8, or $10, or $12, or wherever the price is now, item to a developer one time, then it may be that the product is not worth $8, or $10, or $12, or wherever. And as far as being a loss leader for RedMonk sales, like I said, in our case, we wanted it to lead to many conversations, which it has, certainly from a commercial standpoint, but really, if nothing else—set the commercial relationship aside—the writing of the book, for me was really almost a exercise in essentially simplifying the conversations or, I guess, improving the conversations that I would have externally. So, prior to The New Kingmakers becoming more of a common framework that people discuss, I would have to sit there and make the case, talk to them about developers, and here's some of the trends, and here's why, and so on, and have that same conversation over, and over, and over, and over. And, look, there's nothing wrong with repeatability, certainly in the consulting profession. It can pay bills and so on. But at some point you want to be able to say, “Okay, look, the basics are established. We all agree on this. Now, let's go have the more interesting conversation in terms of, what does this mean to your business? And how do we change this? And how do we fix that to take advantage of the situation, or mitigate your liabilities, whatever it might be?” So, yeah, it was honestly more of an attempt to shift the type of conversations that we had then spin up entirely new ones, in spite of the fact that it is most certainly done that for us over the life of the title.

Corey: Do you find that the book had its intended effect, in that it did change the tenor and character of those conversations, that it got you to a point where you're able to have those discussions in a way that resonated more?

Steve: For sure. Now, I will say that—well, let me answer that two ways. So, the first way is that in cases where people read the book, or frankly even in some cases, haven't read the book, but have seen presentations by, like I said, at Red Hat summits or SAP has mentioned it on stage, IBM, I think Microsoft has. Anyway, so it's been picked up and talked about by many of the largest vendors in the world, who then go out and propagate it to all of their customers. So, in cases where people have read the book, and come to the table saying, “Okay. Yeah, I've read this, I understand these pieces,” then great. It has certainly shifted the conversation. But the second, probably more important context is that, I think, to a large degree—and we say this all the time at RedMonk—we're a small analyst firm, and we have always tried to recognize and to be self-aware enough to understand what we can and can't do. And what RedMonk, as a small analyst firm, can't do is shift the market. What we can do is basically say, “Look, this shift is occurring. Let me tell you what we know about it.” In some cases, like in The New Kingmakers, let me give you a term for it, but, frankly, in a world where The New Kingmakers never gets written, does the market still shift? Yeah, for sure. Because basically, we're talking about massive trends that are in flight: open source, cloud, Software as a Service, democratization of access to educational resources, on and on and on. So, these things were going to have an effect one way or another, whether we knew what to call them, or whether we came up with a name for it or not. So, yeah, certainly in a very narrow and specific context, the book was absolutely able to help improve those conversations, but in all likelihood, they probably would have improved one way or another.

Corey: So, here's the dangerous question. You've had an entire internet of people telling you in a variety of different contexts for the past, well, let's call it seven years. If you were to rewrite the book today, what changed

Steve: [laughs] Oh, yeah, James, put you up to this, didn’t he? Yeah, James, for listeners who are unaware, has been badgering me for several years to write a second—

Corey: And who is James for those others who are unaware?

Steve: I should mention that as well. James is the co-founder of RedMonk. James Governor and I founded the firm way back when. Much longer, again, than I would care to admit. Anyhow, so my co-founder has been after me to write a follow up for a number of years, and who knows, it still could come to pass. It turns out that writing a book when you don't have a child is a lot easier than writing a book when you do. But books are not written solely by people with no children, so who knows, maybe at some point, I'll find the time for it. The short answer is that, I think in many respects, it's a scenario where I sit down to write the second edition tomorrow, it's less debating the concept and proving the concept—which is largely what the first edition was about, but rather—okay, let's take for granted that much of what was predicted has come to pass, and certainly spent some time on what didn’t, maybe, and why, but largely thinking about, okay what's the impact and what does this mean moving forward? Because the world, again, that that book came out in from a landscape standpoint was really different than the world today. And that is just one example. We have seen written; talked about extensively, problems of fragmentation. So, what we mean by that is that if you go back 20 years—frankly, if you go back even 10 years, the volume of available solutions that developers and the businesses they work for have available to them is much smaller. So, one of the things that has happened is that developers essentially took over the world, and they kept producing software, which, at first, it’s great. Anything you could possibly want to do, there's a library for, there's a piece of software for somewhere. But then, you start thinking about that problem at scale, which is, okay, I'm going to need a couple different pieces of software to solve any given problem. And now I have maybe a dozen, two dozen different credible choices within each one of those areas. And oh, by the way, there isn't just one or two or three ways to do things now, there might be four or five or six. So, generally speaking, if we were to think about a second edition, to think about what a follow up might look like, it would honestly spend less time on the mechanics of how developers were empowered, as the first did, and more trying to understand the implications of, okay, what does that transition empower? What does it mean? What are the practical implications of that for both the developer and the businesses alike?

Corey: One of the hardest parts of all of this is you wind up effectively, in some ways, disturbing established orthodoxy, where people push back not because you're inherently wrong, but rather because you are saying things that run counter to the established narrative that they are invested in preserving. Have you seen a lot of that?

Steve: [laughs] Oh, way back in the day for sure. I mean, I can tell you—like I said, RedMonk’s been around for a long time. And some of our earliest roots were looking around—and open source is one example in terms of, okay, hey, we're going out and talking to all these businesses and more importantly, engineers working there. So, we have a pretty good idea of, hey, there's a lot of open source in these organizations, and then you go and talk to some of the analysts at the time, or read some of the reports. And because that can't be measured in the same way because it used to be, all right, we're going to trap unit shipments, we're basically going to track the finances because that was, once upon a time, that was the only way to get software, you had to pay for it. And we just looked at this and said, “This is insane.” You're basically missing a whole class of software that is widely in usage at scale. We saw the same thing later on with the cloud. And I can remember looking at some of the reports, and they were saying things like, “Hey, these x86 hardware segments are leading the market and their future is bright,” and so on, and you're like, okay, what about this cloud stuff? Or what about these ODMs? We don’t have a good way to track that, so we're not counting that. So, when we would point these things out, from time to time, you would certainly get a lot of pushback. People are like, oh, this is insane. Why would I ever care about a developer if they don't have any budget? This cloud stuff is just a toy. The toy thing is a recurring theme. It's one of these—I’ve joked about this on Twitter at one point. When some established technologist calls some other technology a toy, like my ears perk up. I'm like, oh, okay, I’ve seen this play out before. So, yeah, the short version is that we have seen this many, many times over the course of our career, where we're saying one thing that the larger established analysis firms are saying something totally different, and we look insane, frankly. And we've been fortunate that some of the bets that we have made, largely around developers and things that developers use, have proven to be, I think, fairly accurate over time. So, what that means is that for a little while, when you're an unknown and people have never heard of you, then it's much easier to dismiss you out of hand. Once you've been doing it for a little while, and people have some background in terms of, okay, I've seen this stuff before. These people are maybe not totally insane, so maybe I'll listen. So, yeah, I think the short version is that we got a lot more of that a while ago. But we still see that from time to time. People will—oh, I’m trying to think of things that have been more controversial lately—certainly some of the things I have said about open source in APIs and so on, are not popular, and certainly violate the orthodoxy if you will. But as I said, I think we've been doing this long enough, we have a track record that people can look to, and it's certainly not that we're 100% right, or right all the time, or anything like that, but I think people at least are willing to listen in ways that maybe they weren't 5, 10 years ago,

Corey: We can hope that people evolve their listening skills as they evolve their careers, but that's not always a guarantee. And it turns out, there's always a new generation who has to learn things from first principles, that's called Hacker News.

Steve: I see a lot of that in the open-source space. I’ve seen a lot of that in [laughs] I won't name the company for obvious reasons, but there was a company that did pretty well with a particular class of infrastructure software, and we talked to them a couple times; we’re like, “Okay how are you going to make money here?” And at the time, they were super, super successful and, from a visibility standpoint, was not terribly preoccupied by the revenue. And we had said, “Hey, look, we've seen this pattern play out our number of times. And this is typically where people make money. So, is that of interest?” And by and large, it wasn’t. And yeah, that didn't end up particularly well for this company. It's honestly, I mean, you probably go through this, I'm sure, yourself. And I'm sure many of the listeners have this experience, too, which is, one of the single most defining characteristics of really successful people, in my experience, it doesn't matter who they are or what they do is just, just listen. Listen to what people have to say. When we talk to our clients, we tell them this all the time, hear us out. If you think we're wrong, and you can build a case for it, by all means, lay it out, and if we need to update our opinions, we will. But if you come in and think you know everything already then, maybe you do, but you're probably going to miss some things along the way just because you can't listen.

Corey: I think that's probably the best lesson to take from a lot of this. If people want to hear more about what you have to say on this and other topics, where can they find you?

Steve: The simplest way is to go to RedMonk.com. That's where all our stuff is. You can follow me on Twitter @sogrady, S-O-grady at Twitter. And yeah, website and Twitter are probably the best means.

Corey: Yes, showing up at your house is a distant third.

Steve: I would—yeah. Yeah. Office, too.

Corey: [laughs] That works. Well, thank you so much for taking the time to speak with me today. I appreciate it.

Steve: Not at all my pleasure.

Corey: Steve O'Grady, principal analyst and co-founder of RedMonk. 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 Apple Podcasts. If you've hated this podcast, please leave a five-star review on Apple Podcasts, and then go talk to someone higher in the corporate hierarchy about why it is the way that it is.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.