Episode Summary
Be honest: How many people decide to launch a weekly podcast actually end up publishing hundreds upon hundreds of episodes? Richard Campbell, founder and chairman of the Humanitarian Toolbox and host of RunAsRadio podcast, is someone who actually did. Join Corey and Richard as they talk about what it’s like to host 1,650-plus podcast episodes, building open source tools for disaster relief, moving away from legacy tech, the power of admitting you don’t understand something, how snarkiness often gets lost in translation, the thanklessness of good IT, and more.
Episode Show Notes & Transcript
About Richard Campbell
Richard Campbell wrote his first line of code in 1977. His career has spanned the computing industry both on the hardware and software sides, development and operations. He was a co-founder of Strangeloop Networks, acquired by Radware in 2013 and was on the board of directors of Telerik which was acquired by Progress Software in 2014. Today he is a consultant and advisor to a number of successful technology firms and is the founder and chairman of Humanitarian Toolbox (www.htbox.org), a public charity that builds open source software for disaster relief. Richard is also the host of two podcasts: .NET Rocks! (www.dotnetrocks.com) the Internet Audio Talkshow for .NET developers and RunAs Radio (www.runasradio.com) which is a weekly show for IT Professionals.
Links Referenced:
Links Referenced:
- Twitter Username: richcampbell
- LinkedIn URL: www.linkedin.com/in/richjcampbell
- Personal site: https://rcampbell.me/
- Company site: http://runasradio.com
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 week's episode of Screaming in the Cloud is sponsored by LightStep. What is LightStep? Picture monitoring like it was back in 2005 and then run away screaming. We're not using Nagios at scale anymore because monitoring looks like something very different in a modern architecture where you have ephemeral containers spinning up and down for example. How do you know how up your application is in an environment like? That at scale, it's never a question of whether your site is up, but rather a question of how down is it. LightStep lets you answer that question effectively. Discover what other companies including Lyft, Twilio, Box, and Github have already learned. Visit lightstep.com to learn more. My thanks to them for sponsoring this episode of Screaming in the Cloud.
Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined this week by Richard Campbell, a man who is more enigma than almost anything else. Richard, welcome to the show.
Richard: Thanks for having me on, friend.
Corey: Thank you for being had. Your bio says you've wrote the first line of code in 1977.
Richard: Mm-hmm (Affirmative)
Corey: Your career has spanned the computing industry, both on hardware and software sides, development and operations. You were a co-founder of Strangeloop Networks, acquired by Radware in 2013, which around then was about the time I was playing with one of their load balancers it turns out. You were on the board of Telerik, which was acquired by Progress Software in 2014. Today you're a consultant and an advisor to a number of successful technology firms. You're the founder and chairman of Humanitarian Toolbox, a public charity building, open source software for disaster relief. But the way I found you is that you're the host of two different podcasts .Net Rocks!, which I'd never listened to and I would argue the point, and the one that I encountered you with, RunAsRadio.
Richard: Right.
Corey: Which is a weekly show for IT professionals. Stop me if you heard this one. You're a Microsoft MVP and you are more or less the... It seems like a strange version of me who, let's admit it, you're not quite as well dressed, but that's okay.
Richard: That's true.
Corey: I forgive you, but over in the Microsoft ecosystem rather than the Amazonian one.
Richard: Yeah. I do grow a better beard than you though.
Corey: Yes. I still look like an angry 14 year old trying to prove a point to mommy and daddy and-
Richard: Well the show is called Screaming in the Cloud. I think you're supposed to be angry.
Corey: Oh, absolutely. I do my best. But I encountered you a couple years back when I attended my first Microsoft Build, when they sent me an invitation to go and record an episode and I thought, "Wow, that's amazing. They've gotten me confused with someone who knows what they're talking about. Awesome. I'm going to act as if, because as a mediocre white man, that works really well for people who look like me."
Richard: Right. Sooner or later they're going to figure it out, but if I move fast enough, maybe I can get the show in.
Corey: Exactly. And it worked and I had Corey Sanders, at the time the corporate VP of Compute. Now he's ascended somewhere else and we had him on again recently at Azure... at Microsoft Build this year. The interesting part though was that this year you reached out and invited me up to record a bunch of shows and people who've been following this on a week to week basis have noticed since then. "Wow. There've been a lot of Microsoft guests there." Yeah, that was recorded during a three day span when I'm up there trying to I guess maintain focus after the seventh podcast recording in a row.
Richard: You can get punchy after a while when you knock them out back to back like that.
Corey: Absolutely. So I did a little more digging into you and it turns out that as of the time of this recording, you and I have recorded a few days ago, an episode of RunAsRadio, your show, and you mentioned that that would be episode 650.
Richard: Right.
Corey: So I'm not sure on the scheduling, this may come out before that one. But what's fascinating to me is you've been doing this about 10 times longer than I have, so, "Oh, this is what I'll be if I grow up."
Richard: I'm still trying to figure out what I'm going to be when I grow up. All I know for sure is I'm pretty persistent.
Corey: Yeah, and that that seems to work out really well, and I've looked through some of your back catalog of various episodes you've had. We've had some people in common. You have a list of people that are high on my list of folks to wind up dragging and interrogating, I mean interviewing. And it's just been... It's really neat looking at what someone can turn this into. I don't view this as a deviation from the typical theme of this show, which has been the business of cloud computing because you very much have a business that is running around the world of cloud. I'm intentionally vague. I don't say a technology business. I say a business. So you've turned this into a RunAsRadio company around this. You have a very streamlined production pipeline that puts mine to shame. It's just fantastic watching you work.
Richard: Well it's been 12 years. So we did migrate to the cloud, you know? The original incarnation, you're talking about the early days of podcasting. Carl Franklin, my cohort on .Net Rocks!, he recorded his first show in 2002. The word "podcast" didn't even exist yet. And I started out run as of 2007 so the word now existed but it was still very early days. Of course I started an IT podcast that was Microsoft centric right after Vista shipped because I'm clever like that. And so you know, those were tough days the those first couple of years.
But the machine already worked pretty well and it was not hard to just keep every Wednesday, you know, since April 11th, 2007 make sure a show publishes, just keep doing it and the numbers sort of pile up. It's way more fun now that the cloud has grown up and become a thing and we're still exploring what it can do. That's a nontrivial area of conversation, you know, week over week along with topics like DevOps and still, you know, dealing with the reality of do you run a mail server, do you own a domain controller? Like all of those kinds of problems that IT folks have and are just figuring out the right ways to do things.
Corey: Right. Whereas I come from the Linux and startup world here in San Francisco where our entire approach to development is laughing derisively at anything that's more than six weeks old and throw everything away. When everything's greenfield, you can build amazing stuff that never looks bad because you won't be running it long enough for it to become legacy.
Richard: Yeah. By that point, you've pivoted.
Corey: Exactly.
Richard: Where I think, yeah, a non-trivial chunk of my listeners are folks that are still paying the price for decisions made in the early aughts.
Corey: Isn't that the truth? When people say legacy, I hear it makes money and, again, I'm a three year old company. There's only a handful of us here now, but everything we've built is largely serverless and I look back and I still see that I have piles of technical debt. "Ooh, I would do that differently. There's a better way to have done that. Oh, my account management was crappy, et cetera, et cetera, et cetera." But it doesn't actually solve any business problem for me. If I fix that, it just assuages my sense of something not being right in the world.
Richard: It's also a balancing act on those things as well, right? You have it pivot moments like I'm about to renew this contract for the next two years or five years. This is the moment to make a decision like how much will I regret this when that contract expires that I did this again? Shouldn't I make a move to the code or do a rearchitecture, retire or a piece of technical debt? There's only certain moments when it makes sense to actually pursue that. They slowly cost you, right? They are hammers in that sack of hammers you're carrying around and, you know, the chance you get to shake a few off. It's pretty compelling.
Corey: It really is. But what's also interesting to me about you is that you and I have both gone to the same direction where to some extent we've stopped writing code day to day, 40 hours a week and started doing other things. And the podcast is fascinating. I view you as someone I can reach out to from time to time and get good advice and figured it's probably time to wind up putting you on the show as well. But from my perspective, when I started this, it was, "Well, what do I do with the podcast? Like how do I structure this show in a way that makes sense for people?" I know I wanted an interview show for starters for two reasons. The aspirational of trying to help other people tell stories and effectively give them exposure to a new audience. And the real answer, which was, "I'm a nobody who no one should ever listen to seriously." But when you say, "Would you like to be on my podcast?" People say, "absolutely" instead of, "Who are you? Get out of my office."
Richard: How'd you get in here?
Corey: Exactly.
Richard: I also... I've discovered how powerful it is just as a research vehicle. You have these amazing conversations where ultimately you're... You represent the audience while just helping to try and understand what's going on, what they're talking about, and if you can clarify that, you'd probably clarifying it for the listener as well. But you ended up in this sort of state, this gestalt state, this, "I have a sense of a view over this platform because I've talked to all these different people and then gotten feedback from my listeners." And so I sit in a sort of interesting analytical space where it's like, these things seem to be important for the companies that are selling them, but not that important for the users that don't really care about them.
Corey: Right. And there's so much coming out across this entire environment, sort of cloud ecosystem, that no one can keep up with it all by a landslide. Picking and choosing different aspects of it. And when you get someone in who's well connected in the environment and being able to ask them what parts of this matter versus what parts of this can be safely ignored or even not even framing it that way. It's cool. Like when I had Corey Sanders back on or Scott Guthrie, it was great to be able to talk to them about the entire Azure ecosystem, something I don't know much about, and see what areas they focus on. Because there's so much they could talk about, but instead they pick one or two areas that they're excited about, that they want to tell a story around. And that helps contextualized and shape how I start to view that ecosystem as a result.
Richard: Yeah, absolutely. And I think for your listeners as well, just to be more aware of this larger cloud world we're living in and say like, "Who's moving where?" Because it certainly... Amazon and Microsoft are paying close attention to each other.
Corey: Oh, absolutely. I tend to feel like I personify my listener reasonably well because, for better or worse, through most of my career, I have always been usually the first person in any given room to stand up and say, "I don't get it. There's something that I'm missing. There's something that is unclear to me and it's just not clicking." And invariably, whenever I do that, other people chime in. "Yeah, me too." I did an-
Richard: Right. That sort of relief that grows across the room. Oh, it's not just me who's like, "This makes no sense."
Corey: Right. Today we're recording this on July 25th of 2019 and late last night, right before I went to bed, I tweeted that I just spent a few hours wrestling with S3, trying to get URL redirects working, gave up rage quit, did it in 10 minutes in Nginx on an EC2 Instance, and went to bed. And the replies to that that I woke up to, massive, fall into two camps. One of them is, "Well, have you considered..." And then it gives some Archaean, Byzantine serverless solution. It's no because I have a job.
Richard: Right.
Corey: And the other is, "Oh, thank God. It's not just me. This stuff is super complicated." And that's why I mention, "This makes no sense to me and I don't get it" as often as I do because when I do that it reminds people that they're not alone. So if I don't understand a lot of things about a product or an ecosystem, and I call that out, I feel like in many ways I'm speaking for the users when I do that.
Richard: Well, I mean particularly in this space, you're often working alone anyway. There's lots of people depending on you, but you are the "expert", you know? You're handling our cloud migration, right? And you're like, "Yeah." Or when you get that pop up dialog that says, "This didn't work. Contact your administrator for more help." And like I'm the administrator and I have no idea what you're talking about. So I think having a show, these kinds of conversations, because you're often alone, it's like this is your one connection that reminds you you're not alone. That there are other people struggling with this, that this is a normal part of us building a new part of civilization, which I mean I'm not exaggerating. I say the cloud is reshaping what humanity is going to look like and our small roles in it, whether you're building it, utilizing it, or talking about it all are part of moving that ball forward.
Corey: One of the things that I guess astonishes me is just how well this has resonated. I thought this was going to be something I do for a couple months and then shut down and here we are well over a year later. Well not shutting it down now, but what's strange is you know, no one ever knows their own reputation. What you mentioned to me is that getting guests for the podcast initially when you were working behind the scenes where I knew you were doing that was challenging based upon the name of the show.
Richard: Yeah. Well you know, first impressions and visceral responses, but also non technical people. I mean when you're talking about working around an organization in a conference as large as Build, there's a lot of people who have says in different things and so they come at it from different perspectives. And if there's PR folks involved, well they care about the optics more than anything else and and they're going to go on the simplest, easiest response. They got to triage hundreds of things and what's the quickest way to do it? It doesn't make it accurate.
Corey: Right. The show is called Screaming in the Cloud. Obviously it's a ranty thing that's looking an awful lot like you just sit there and berate someone for half an hour.
Richard: And unless you actually listen to the show, in which case you know, that's not even remotely true.
Corey: Right. But when I started this, I didn't know what it was going to turn into and I learned a lot as I did this in the first dozen episodes or so. For example, I thought this was going to be sarcastic, snarky, and bantering. It turns out when there's an interview show and you have a different guest on every week, you can't do that in the same way because if you and I banter and we're snarky and we're sarcastic and you smack it back every time I toss something your way, it's a great show.
Richard: Sure.
Corey: But the next week I have a different guest where they are not as good at this and it looks instead to all the world like I'm beating them up. Someone listens to that, no one's going to come out of that thinking, "Oh, I'm going to be on that show." Hell no.
Richard: And it's not fun to listen to either if someone's confused or struggling. You know, we have the advantage that we've known each other for a couple of years now. I mean not every day, but they got a couple of events, you know, and so I'm pretty sure I know your snark when I hear it.
Corey: And we both do podcasts, so we definitionally have the ongoing love affair with the sounds of our own voices.
Richard: Well, I do sound amazing.
Corey: Yes, I have a face for radio. It works out well, but what's fun too is that as I was looking down this path, I realized about, at the time of this recording, a couple months back now that I wanted to have a podcast where I could be snarky and sarcastic. So I launched another one, the AWS Morning Brief and that's now about two months in where it effectively right now is on Monday mornings. It's a 15 minute show and it just talks about the releases that AWS has done over the past week like I do in the newsletter. And then I make fun of them as I do in the newsletter, but I often go into more depth. I talk about why it matters. I mention things that don't fit in the newsletter for whatever reason. I go off on tangents from time to time and I'm snarky and I'm fun and it's sarcastic and I don't have a guest so I don't need to worry about making anyone look bad.
Richard: Yeah.
Corey: There are plans for You Heard it Here First to look at expanding this to a multiple day a week show.
Richard: That's a lot of commitment, friend. Like because all that stuff is super timely.
Corey: It is. But that's the trick. I don't think I could do a daily show, for example, about what they released yesterday because, spoiler, no one really cares. People want to get a roundup, but they don't need to have it as breaking news. So there need to be other things to do, like talking about services, doing some sort of deep dive or whatnot, talking about things that are relevant to the ecosystem. Because frankly, just talking about releases, I get bored, let alone other people. I can't imagine what that would look like. You've got to keep it fresh. You got to keep it interesting. You got to keep it snarky.
Richard: Yeah. Analysis of an outage is always interesting. Like what really happened with Cloudflare the other day. You know, I know we've been making fun of their mistake, which is lovely, you know, because-
Corey: I have such little tolerance for that. Yeah. It turns out all this stuff is super hard. Anyone who's sitting there saying, "Oh, you went down because you employ morons who are terrible at these things." Shut up and go away.
Richard: It's not even close to true.
Corey: Yeah, it's very clear that whoever's saying that has never had to run anything of any reasonable sense of scale or importance. So if you've... Like one of the questions I always liked to ask people when I was an ops manager in the interview was, "Tell me about an outage that you were at least partially responsible for." And is always is partially responsible for. And people's reaction to that is telling. I don't want to see people beating themselves up, but I want to see people telling a story about it and if the answer is, "Oh, I've never taken production down."
Well there are a few things that are possible, none of them are compelling. First, either you're lying because you think it's an interview and you're never supposed to have broken anything, which cool, we're done here. Or no one has ever trusted you with production, which, okay, that's interesting as a data point. Or you are so methodical and so careful that you need to quadruple check everything. We're at launching space shuttle style of software rather than something that's web facing. And that's also useful to know and we'll uncover that as we have the further conversation. But-
Richard: Yeah. You don't even know if the space shuttle is a good comparison because they didn't... That didn't always work out well for them either.
Corey: Oh yeah. It was great. I got to tell that story once from an outage that happened in a team I was running. Someone on our team wound up doing a misconfiguration that led to something else and an edge case hit it. That's always how these outages tend to happen these days. And the discussion was "Okay, so that misconfiguration really... Like any one of those things not happening would have meant no issue. But that misconfiguration..." And the interviewer leaned in and said, "Was it you?" And my response was, "It was the team I was managing. So yes, of course it was my responsibility, but who actually made the mistake completely irrelevant and it could have been any one of us." It's the truth. You don't blame people for individual mistakes. The one that irritated the living hell out of me was the S3 apocalypse a few years back where... "Oh, it was a typo on the command line."
Corey: No, that effectively meant someone stepped on a landmine that many other people had a contributory effect in burying. If one wrong command typed into the wrong place can take down all of S3 for an afternoon, well that is a process and systems failure and it's a learning experience. I've never figured out who it was and the only reason I'd want to is so that I could call them and say, "You know what? We've all been there. Can I buy you a drink?" Because man there but for the grace of God, any one of us could have had something like that happen and it's certainly not their fault and I just want to validate that there was never any direct consequences to that person. I don't imagine there would have been, but-
Richard: No, not that you would presume in these big organizations, they're mature enough now to know that this was a failure of process to even be put into that situation where it's possible to do that.
Corey: Yes. Andy Mai-Lan Tomsen Bukovec, the VP of S3, was on this show very beginning of this year and we touched on that topic as well. But before the system had been restored, there had already been changes pushed out that would've prevented that mistake from ever happening again. They've also gotten onstage since then, various folks from her organization, and talked about how it's now running, I think on 235 microservices that drive S3. They've completely rearchitected a lot of it under the hood and we're seeing performance and stability enhancements come out of it and contextualizing that's important, but telling the human story around these things is always interesting because a root cause analysis...
I feel like companies are sort of becoming victims of a situation they've created for themselves where marketing and PR only ever released very carefully crafted statements so people are used to having to sort through those for subtext but root cause analysis or cause of error reports or whatever term we want to use so J. Paul Reed doesn't yell at me are all very... Those tend to be very honest and... But try to dissect that into the, "who screwed up?" Is counter productive and unhelpful.
Richard: Yeah, no understanding how we can get into a situation like that and how we're not going to get into it again is the real root cause analysis. That we get to a place where now we... Analysis isn't good enough if there's no action to take at the end, right? The whole point is to get to a place that says, "If we take this action, we decrease the likelihood of these kinds of problems."
Corey: Yeah. So I'm a consultant these days. I fixed the horrifying AWS bill. I opine on architecture a lot, but I don't really run production infrastructure anymore. So one of the things that I worry about, and I'm curious how you've addressed it, has been now that I spend the bulk of my time, at least as far as the public sees it, of doing podcasts, writing newsletters, and being obnoxious on Twitter, how do you avoid losing touch with the technology to the point where you just become a talking head who hasn't ever used the thing that they are taste making about?
Richard: Yeah, I do think you have to use the thing, right? And it may not be large scale websites. It's your own stuff, but that's fine. You know, actually spending time in the tool matters a lot. I laugh because of course doing RunAs now for 12 years, I continued to run my own exchange server. I was allowed to. I have the license for it. It makes no sense. It should be in the cloud, but I can also look an exchange admin in the eye and say, "Dude, I feel your pain." Right? Like running mail services is a thankless job. Well most of IT is thankless, right? You can only get a C or an F. If it works, nobody can tell. And if it doesn't work, well you're an idiot. There's nothing... There's no win. It's just you made it through another day. Have a beer. Keeping the infrastructure up and running for the show is part of that.
What's the right way to do this? When do we improve it? How do you think about the sort of next stages on that? At the same time you're having conversations with the people that run these larger installations and, you know, pursuing this case studies. In the early days of Azure, I stopped talking about it on the show because the only people I could get to talk about it were the people building it and the folks that were talking about the people who are building it. I just hit a point where I'm like, "Until you have a case study, until there's somebody running it that it's meaningful, I don't think this is worth talking about anymore." Because that's, I think, what people actually wanted to hear. "Talk to me about a regular group of humans who use this tool successfully and what they liked and what they didn't like." That to me is a useful conversation. All too often you're caught in the... You can be stuck in the bubble of the people who want to promote it more than the people that actually are using it.
Corey: One of the things that astonished me as I did this because I started off building all the infrastructure myself because, "Hey, I run infrastructure. It's what I do." The newsletter and the podcast and the rest have gone from toy projects to viable businesses and at that point I felt a sense of responsibility to stop keeping this all with this Archaean architecture I built in my head. I migrated all the web properties to WordPress. WP Engine hosts that. I'm giving a conference talk about moving it off of serverless and onto WordPress over at Serverlessconf in New York later this year called Benjamin Buttoning Serverless. And I expect to mostly be shouted off the stage because it's something that flies against common wisdom and true believers. Which, okay, I get, but by the same token, I want to make sure that we're actually doing things that are right for the business.
What astonishes me is I... Whenever I find myself talking to analysts, they look at me and they think I'm a kindred spirit because I talk to the people building these things. Yes, I do. Then I talk to customers using them. Yes, I do. And then I build something with it myself to validate what I've heard. And invariably when I tell that to an analyst, I get a flicker of terror in their eyes as if somehow-
Richard: What would you do that?
Corey: Well not even that. About am I about to be the kid that points out that the Emperor has no clothes? Because you have entire analyst firms that never touch this stuff that are very good at talking about it. And I never want to be that.
Richard: No, and I think it's a conscious choice that you also make in your work, right? I mean, the good news is, especially when we're talking about the cloud space, is that we're all using it to some degree. It's just how aware are you and how responsible are you for it? It'd be way harder to be in a space that was much narrower, more specific where you really wouldn't have any excuses to utilize it. But I think we also make a choice, right? It's interesting that you pulled away from a serverless architecture over to WordPress Solutions. Sounds like very practical engineering and I think people-
Corey: Oh, absolutely. I could hire someone to handle all this stuff for me in the development side. I can pay a company probably too much money to host this all for me and I wouldn't have to think about it or touch it. Whereas finding someone who can do that same sort of work on the bleeding edge of serverless stuff, well, okay, that's not a basket full of money. That's a dump truck full of diamonds. So it gets incredibly expensive and for what business value? Because again, "Well you'll have better availability and utilization, et cetera, et cetera, et cetera." Yes, true. However-
Richard: Will I? If I actually have to take care of it myself because I'm awfully busy.
Corey: Right. My time is worth more than the infrastructure cost at this point because it's the opportunity cost of not doing something that adds business value.
Richard: Well I think you get more uptime out of having... You have people who can take care of it, even if it's a bit more fragile. Like the people factors on all these things matter. The availability of resource matters, right? You have to be able to scale and it's not just, you know, scaling the site, it's scaling... Having people around that you can trust to make sure those things keep working.
Corey: Right. And if WP engine falls over, they have an entire team of people who are paid to do nothing other than make sure that that doesn't happen and they're going to get it up and running and notice it way more effectively than I am. Yeah.
Richard: Long before you do. And that's all the point of the cloud is we're concentrating the best and brightest around these infrastructures. So they do-
Corey: And my use case isn't what people tend to... I think that people lose sight of that. If I'm an ad network, for example, people are not going to come back if my site is down and try and view an ad later. Every second there's down, there's a very real revenue cost of that. With last week and aws.com, which has my blog, the podcast, the newsletter stuff, if that's down, someone's not going to be able to sign up for during the duration of that happening. But it doesn't have a direct revenue impact on me. I mean, I'm still averaging a hundred signups a week on the newsletter, so if I'm down for 10 minutes or so and I wind up losing at a high side 12 of those, it's not good. But it's certainly not the end of the world economically.
Richard: Yeah. It's also a challenge to measure that too, right? You don't have a-
Corey: Right.
Richard: Equation to that. Yeah, will those 12 that couldn't get there come back later? Like those are hard questions to answer, but it's all still the same basic point, which is, you know, the value prop here for the amount of effort necessary and costs necessary is high enough that this is the best way to do it.
Corey: It really is.
Richard: There's no ideal logs, right? I mean, if you really cared to optimize everything, you'd still be handcrafting C++ and CGI calls for this, right? We don't care that much. We don't need, you know, the difference between a second and a 10th of a second. It's just not that big in this scenario.
Corey: Exactly. And at some point, Charity Majors had a great line that she's said a few times that "Nines don't matter if users are unhappy."
Richard: Yeah.
Corey: And that works in the direction of the experience needs to be good. Just technically saying you're up doesn't count. But by and large, if people don't care that my site is down at any given point in time, then is it really a problem?
Richard: Oh yeah. Right up until the cashflow stops, you know?
Corey: Well, there's that. Then I have a problem. So as we take a look back over the sweeping landscape we just covered, we've talked a lot about where we've come from and how we built these things. What's the future look like for you?
Richard: Well I you like... The podcast model, I think, appeals because it isn't your principle focus. I don't think a lot of people sit down and just listen to a podcast. They tend to listen in their car on the way to work or their transport of choice or when they're working out and so forth. So you know, I'm big on the in the ears model. I think it's very interesting. The question is always are we telling stories that people care about? Are we staying focused on those kinds of things? And are we cross pollinating? You know, here we are crossing the streams, you and I, between my show and your show and certainly the same thing we were doing at Build with all those podcasts.
We're all way more alike than we're different. And the more times that we can sort of mix that up or remind each other that everybody's working hard, trying to do the right things and that all of these technology choices are viable, right? There is no one right way. There's what you know, how well you can manage those costs, and how much value you get from it. I think the more times we understand that with everyone in this particular circuit, the happier we're going to be.
Corey: I think you're absolutely right. The very honest truth, one of the big reasons I have a podcast that does interviews, is every week you get to borrow someone else's audience. What always drove me nuts is when I would guest on podcasts and they wouldn't promote it. It's... What's the point of having me on your show if you're not going to ask me to tweet about it or leverage my audience? Because that's the entire point.
Richard: Yup. That is absolutely the machine and more sources of good information, people want to know about them. They're valuable. So it's certainly, it's worth putting energy into putting that out in the world. We still have Engineer's Disease, right? Which is, "If I make it, that should be sufficient. If you don't value it, well that's on you." But that's not the truth, right? There's plenty of great things that have been made over the years that nobody got to know about because it didn't put the effort in to making it visible.
Corey: I think you're absolutely right on that and I think that's probably a good place to leave it.
Richard: For sure.
Corey: Richard, thank you so much for taking the time to speak with me today. Where can people find out more?
Richard: Well, for this particular audience, come and listen to RunAsRadio, which is exactly the domain name as well. And that website is filled with CIS admin jokes. So if you take a look around, you'll see little things that if you're a CIS admin, you think that's funny. And we put out a show every Wednesday since 2007 so you know, you can count on us to be there. And otherwise you can reach me on Twitter. I'm Rich Campbell on Twitter and always happy to chat and snark and have some fun with this great career that we're in.
Corey: I'll be sure to throw a link to RunAsRadio.com in the show notes, but that link will be largely symbolic.
Richard: That's how all of them --
Corey: Yeah. Welcome to the CIS admin joke pool. It doesn't get better from here. Richard Campbell, Microsoft MVP, founder of several podcasts, RunAsRadio.com, and raconteur for lack of a better term.
Richard: Nice.
Corey: I'm Corey Quinn. This is Screaming in the Cloud.
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.
Announcer: This has been a HumblePod Production. Stay humble.