Get ready for some spicy takes as Adriana geeks out with Tim Banks of Dell Technologies! In this episode, Tim explores the repercussions of company-owned open-source projects shifting towards closed-source models, using the recent case of HashiCorp's Terraform as an example. He also shares his insights on how a company can stand out from its competitors by focusing on improving its software instead of resorting to acquisitions. Adriana and Tim delve into the significance of transparency and open communication within a company, emphasizing the critical roles that both technical and non-technical positions play in driving a company's success.
About our guest:
Tim’s tech career spans over 25 years through various sectors. Tim’s initial journey into tech started in avionics in the US Marine Corps and then into various government contracting roles. After moving to the private sector, Tim worked both in large corporate environments and in small startups, honing his skills in systems administration, automation, architecture, and operations for large cloud-based datastores.
Today, Tim leverages his years in operations, DevOps, and Site Reliability Engineering to advise and consult with the open source and cloud computing communities in his current role. Tim is also a competitive Brazilian Jiu-Jitsu practitioner. He is the 2-time American National and is the 5-time Pan American Brazilian Jiu-Jitsu champion in his division.
Find our guest on:
Find us on:
Show Links:
Transcript:
ADRIANA: Hey, y'all! Welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela, coming to you from Toronto, Canada.
And geeking out with me today is Tim Banks. Welcome, Tim.
TIM: Hey. How's it going, Adriana?
ADRIANA: Good. And where are you calling from today, Tim?
TIM: I am calling from the balmy summer capital of Austin, Texas, where it's been over 100 degrees for 40 somewhat days straight.
ADRIANA: Wow, that is very hot. I am definitely like a tropical gal, but I don't know if I could do 40 degrees over 100 degrees, which I guess is like 40 degrees Celsius for that many days straight. It's a lot. Ouchy. Ouch. Well, stay cool. I hope.
TIM: Yeah. Literally, right off camera, I've got my Govee stick fan. Literally, I'm touching it right now, so I have it strategically positioned.
ADRIANA: That's awesome. Yeah, nothing like a good fan to help cool off. Yeah, I have one in my office in the summer because it gets like, so hot.
TIM: Yeah. I face the window, which is great for the lighting, but also then it gets, like, hot in here, so...
ADRIANA: I know, right? Yeah, I have the same problem. All right, well, let's get started with some lightning round questions. All right. I swear they won't hurt. Okay, question number one. Are you a lefty or a righty?
TIM: I'm left-handed...
ADRIANA: Yay.
TIM: but because my dad taught me how to do, like, most sports things, so I throw right handed.
ADRIANA: Oh, interesting. That's pretty cool. Yeah, it's funny, there's like, certain things where I think I'm a lefty as well, but I do certain things right-handed. Like, I could not even fathom using a mouse left-handed. That just feels super weird to me.
TIM: Yeah, it does.
ADRIANA: But I know some left-handed people who are like, yeah, I mouse left-handed.
TIM: Yeah. I've switched around. I'm like, that's just weird to me. Right? Same.
ADRIANA: Yeah. Also my check marks are right-handed people checkmarks. My mom, who was left-handed, did the left-handed people checkmarks, which were backwards or mirror images?
TIM: Yeah, I know. Yeah. It's a pull instead of a push. I still do the push on the check mark, too, because just because.
ADRIANA: Yeah, which makes sense because of being left handed, but I think it was like, that conditioning. So anywho yeah, cool. Okay, next question. iPhone or Android?
TIM: Oh. iPhone. All day long. All day long. I make good tech money. I don't need a Walmart phone.
ADRIANA: Love it. Okay, next one. Mac, Linux or Windows?
TIM: Depends on what I'm doing. Windows is never the answer, but I have to use it if I'm gaming. Fortunately, I'm not a PC gamer. I use consoles, so pretty much Mac most of the time. But if I'm doing running a server or something like that, it's going to be Linux.
ADRIANA: Fair enough, fair enough. All right, next one. Favorite programming language?
TIM: Python
ADRIANA: Me too. I love Python. Okay.
TIM: It used to be Perl, but then Perl just gets really difficult to read after a while, and I don't have that kind of time anymore.
ADRIANA: I've never done Perl, but my job before the current one, they had a lot of Perl and I'm like, damn. I'm not going to lie.
TIM: Perl powered Web 1.0. Right? If we're going to be honest, all the cool stuff was done in Perl a little bit. There are some other Johnny-come-lately languages that really got into the later version of the web. But your original cgi-bin stuff, like all the cool stuff yeah. All Perl. That was all Pearl, man. You get it?
ADRIANA: I rember that. I never got into Perl, but yeah, that's what I remember it from.
TIM: I'm like anyone doing the complex web stuff back in the day was like, it was Perl. Yeah, it's all Pearl.
ADRIANA: That's cool. Okay, next question. Dev or Ops?
TIM: Oh. Ops. All day long, Ops makes things happen. Look, here's my take on it, and it's going to be spicy, and I don't care, but...
ADRIANA: That's awesome.
TIM: ...devs are worried about being replaced by AI. Ops is not.
ADRIANA: Interesting. I feel like we need to dig into that one a little bit later.
TIM: Mm hmm. Oh, we can. We can. I have opinions.
ADRIANA: Very intrigued. Next one. JSON or YAML.
TIM: JSON.
ADRIANA: All right, next one. Do you prefer to consume contents through video or text?
TIM: Depends on the content. Right?
ADRIANA: Mmmm!
TIM: I don't typically like video shorts, so I like little microblogs, but anything of any substance, I like in video because I throw on a video essay and just kind of do whatever. Text is fast. If I want to consume it fast, it's text. If it's going to be anything longer, it's going to be video.
ADRIANA: Yeah, that makes sense. And then final question. I just added this one on, which I actually like to ask in interviews. What is your superpower?
TIM: Oh, gosh, that's a hard one. So my superpower is understanding people...I think that is a good superpower...kind of digging in and getting behind the eyes a little bit on them and figuring out what's going on. That makes a lot of sense. And I feel like it fits in with the DevRel life because we have as much tech in our work as we do, like, the people side of things. Yeah. Understand. Understanding. Not like I use this, but like, okay, but what are you really trying to do? Right? What is this thing trying to make you help? What is keeping you up at night that this will keep you from keeping keep you from keeping up at night? I guess maybe.
ADRIANA: Yeah, that makes a lot of sense. Absolutely. And it's funny because it makes me think of so many times at work where people will come to me and they're like, I need X, and then so I think the gut reaction for a lot of people is like, okay, let's make that happen. But one thing that I've learned over the years is like, but why do you need X? What are you actually trying to do so that you have that extra bit of context? Because maybe you don't need X, maybe you need Y.
TIM: So I think the main problem that I've found in software development cycles is that we are so removed from what the customer actually needs and wants.
ADRIANA: Right.
TIM: Because you think about the customer, how many people that a customer talks to before you actually get to the thing where you're going to develop the thing that you think they're asking for. Right? They're going to talk to a salesperson, they're going to talk to a CSM, they're going to talk to a TAM, they're going to talk to a DevRel. Right? Maybe they talk to company leadership. Right? That gets distilled down and fed to a product manager, who's going to distill something down and feed it to a project manager, who's going to make requirements that you as a developer are going to then try to accomplish. Right. But you don't actually know what the customer is trying to do. And without that context, you're flying in the dark. I've often said that development without context is just masturbation. Right? Because you're doing the thing that you think is right. It makes me feel good, but I don't know if actually no, if it's accomplishing what the other person needs.
ADRIANA: Yeah, that's absolutely true. And it's interesting because I think as much as I get annoyed by Agile, I think it tries to bridge that gap a little bit more by getting the right people talking to each other versus the old ways of Waterfall, where I worked at a bank for eleven years and the developers were so far removed from the business people. We had the business people, then we had the business BAs and then we had the technical BAs and then we had the developers and it's like, what the hell?
TIM: It...honestly, though, I still feel like Agile and the Sprint system still operates without a lot of context. Right.
ADRIANA: Yeah, yeah.
TIM: Because we're taking most of our cues from sales, if we're being honest. Right. And that's why I think DevRel is really important because we're the ones that talk to the users and the customers and the community. Right? And so the DevRel should be an engineering role more than anything else because we should be talking directly to product. Product should be talking to us. We should be talking to the engineers. We should be connecting engineers to the people. Like, yes, I love to go up there and give. Well, I don't actually don't love giving. I actually love talking. I love going there, being on panels and stuff like that. But really, who should be at the booths is not DevRel folks. It shouldn't be salespeople. It should be the engineers who are working on the product and the product managers like that. They're the ones that should be talking to the community and to the customers and the users, not salespeople. I mean, yes, your DevRel folks also, but we're going to do that anyways. Right, but if I want to make the most out of an in-person function, I want the people who are building the things that we're selling interacting with the community as much as possible, not the people who are selling. Right? Salespeople at a conference is really not it. It's not it, you know what I'm saying?
ADRIANA: Yeah. I know what you mean.
TIM: When you walk down to a big city and you go past a place and people are barking at you to buy this thing from the thing that you're really not interested in, that's what that is at a conference. And it's not cool.
ADRIANA: Oh my god, that's so true. It's so true. Yeah. And it's interesting because you seldom ever see at conferences...like, the engineers attending. Every so often you will get that, but especially like at a startup where everyone does everything...but at the larger companies you're absolutely right that you see mostly the DevRels or the sales folks at the booth.
TIM: And so we need to fix that. Companies like, well, we can only send, like, however many people I'm like, you can send more. You just don't want to, first and foremost. And it's like, you don't need to send salespeople, right? They're going to get the leads from the thing anyways. Right.
ADRIANA: Yeah, absolutely
TIM: That's all well and good, the leads that no one's going to respond to. Right. But if you really want to take advantage of being in proximity to the people that use your products or who could potentially use your products, it's the people that build it.
ADRIANA: Yeah, it's so true. And it makes a deeper connection because I remember I've worked the booth before doing lhe lead-generation. Like, oh, let me scan your badge. And it's a very impersonal thing. And then when you have your badge scanned, and then you go back to the office after a conference and you're getting all this bullshit spam email, and you're like, oh, my God, just stop. It's irritating. I don't want to talk to you. I'm going to unsubscribe from your list ASAP. Like go away.
TIM: Or they give you the drip campaign, which I hey, I know we just talked, like, the four or five replies. I'm like, Bro, I have not replied yet to you, so I'm not sure why you keep emailing me, but it's a sales thing. It's like this thing they teach you... oh, you just keep reaching out. Like, no, man. I don't know why this became a thing. You know who I want to talk to? I don't want to talk to those salespeople, right? If you want to intrigue me on something, let me talk to the person who built it.
ADRIANA: Yeah it's so true, it's so true. Talk to the real geeks out there.
TIM: I think where we come off the rails and a lot of that development, like I said, is just we operate without context or we think we did something great, this innovative thing, and then the customers are like, yeah, it's not that I want to actually use that thing. It's not that great, or what's going to make the biggest impact. I would have much rather you did this, right? Because we prioritize a feature based on sometimes a specific sale or two or three customers, right? Because it's big numbers right away for these two or three customers. But you could have much bigger numbers if you met the needs of a lot of customers with a feature or with a fix, and then they grow in your product. Right. I don't need to sell a million dollars next quarter. Or what I need to do is I need to sell $20 million over the next three quarters.
ADRIANA: I remember I've worked with previous jobs with vendors where they're obviously a small startup and we're obviously their big client. And so they are bending over backwards to get your business and putting certain feature requests on hold for your feature request because you are the big screaming client, which ends up being a detriment to...
TIM: Always, always.
ADRIANA: the company I think, as a whole.
TIM: Because you have that one customer you cannot lose.
ADRIANA: Right, yeah, exactly.
TIM: And that is a growing pain, because you have now stopped being a company and now you're a contractor.
ADRIANA: Yeah.
TIM: You're pretty much held hostage by this one client and you have to bend to their will which is a very uncomfortable place to be in. There is this kind of bravery, I would say, almost, that comes...it's actually called leadership...that comes with saying, like, hey, no, this is the vision. We're going to actually develop the product to meet the needs of these customers. If you want it, great. You can buy it. That's awesome. If you don't like it, I want to know why you don't like it, right? And then maybe we can fix it. But also, I'm not going to bend over backwards just for you to the detriment of everything else. Right?
ADRIANA: Yeah, absolutely, absolutely.
TIM: And so I think the weird part is that people are like, there's a thing that you have to pursue this right now. We need this right now. We read this right now and a lot of people are playing checkers and we need to be playing chess.
ADRIANA: Yeah. I love the prop.
TIM: I don't know if this is going to be video or audio or not.
ADRIANA: It's going to be both, actually So the people that watch this will enjoy the clack fan. I am so happy you brought out the fan actually.
TIM: I actually have one that says shade on it, but I left that in the other room. So you just get the rainbow fan. But the point still stands.
ADRIANA: Absolutely. But it's interesting on that same point. I think it also brings to mind this whole mentality, especially in corporations. And I think you see this the larger the corporation, where people stop having honest conversations with each other. You're so hell bent on not disrupting the hierarchy and like, oh you went over someone's head. Or people are afraid of owning up to their mistakes because of whatever, makes it very hard to be productive.
TIM: There is this...almost politician-like cop-ing out on accountability.
ADRIANA: Yes.
TIM: No one ever wants to admit a mistake, or no one really wants to admit the true reason behind something, which is just, I want to make money, right?
ADRIANA: Exactly.
TIM: Let's take HashiCorp, for example, right? They come in here with this, oh, we're protecting open source. And by doing this and people doing this and not contributing...like, no, bro, you had an awful quarter and you're trying to make investors happy. You can just...just say that I would have much more appreciated that than feeding me copious amounts of bullshit about the open source community that you just hung out to dry, right? And in the end, it's going to cost you in the long run. I don't know about a career limiting decision, obviously, but it's certainly going to be a scope-of-influence-limiting decision for HashiCorp over the long run. Right? But they were thinking about this quarter and next quarter, right?
ADRIANA: Yeah.
TIM: And I'm sure it's going to make some investors are going to be like, okay, great, they're doing something great, but it's not going to be good in the long run. The community is already looking at this and going, all right, well, it's a mistake to rely on a single company for this, so let's either look for an open foundation or do we even need this at all?
ADRIANA: Yeah.
TIM: Think about it. When Terraform first came out, there wasn't really a good, strong API for interacting with a lot of the ways we consume hardware and infrastructure resources, right? So Terraform is very useful to have something, especially as an alternate to Puppet, right, because it was open source and much more usable and much more elastic, I guess, in those ways, keeping state and being able to compare things like that, committing things to GitHub, etc. etc., right? That's not the case anymore, right? You can have programmatic access to hardware and infrastructure provisioning APIs and health checks, and state have whether you've got CDK and CloudFormation AWS, Google's got whatever it's got. I'm sure Azure's got some VBasic scripts or something like that you can run. I'm kidding. I'm just throwing shade, Azure.
But the thing you really have to ask is now, do we need to have another entire product for infrastructure-as-code, which is what it comes down to, or can we now use the native tools and native APIs we have and store state somewhere else? The answer is yes, there are open source alternatives to doing exactly that. And we were never really forced to examine our need for it until Terraform said, ha, we're going to change the license. Right? And then now people can just decide to make you irrelevant, which never would have happened if they had done this. People were just happy on like, okay, cool, we'll keep using Terraform because there's no reason to examine it. Now they have.
ADRIANA: Yeah, it's true. And it's interesting because Hashi fans are like, there are hardcore Hashi fans out there, and I do feel like it alienates a lot of them.
TIM: It does. And I think the interesting part is that the people who are Hashi fans now, where is your allegiance? Is your allegiance to the company or the product?
ADRIANA: Yes, yes...
TIM: And those are two different things now, right?
ADRIANA: Absolutely.
TIM: Or they were two different things and now they're the same.
ADRIANA: Yeah, it definitely brings that more to the forefront, as a result.
TIM: The...you know, you got a lot of discourse, you know, especially people like Kelsey who are saying, really talking about what does it mean to have open source maintenance, or how do companies, large corporations with capitalistic interests, what influence do they really have on these things? Or how should they be allowed to participate in these open source projects in ways that don't hurt the community, right? And so you really do have to kind of ask it's like, what do we as a community of practitioners and users and influencers and decision makers and things like that, what are we going to do to really change this going forward? Right? And we do have the ability to influence that. We can change that. It's just a matter of are we going to, we're going to dedicate the time and energy to it or are we going to abstract it away like we tend to want to do with everything else?
ADRIANA: Yeah, absolutely, or it could be that someone gets pissed off enough, and then... what was the...I want to say there was, like, MySQL that they closed sourced, and then they forked it off to an open source version. Am I getting that right?
TIM: Yeah, that was right. Oracle got it and did all that. And then well, I think first it was like when MariaDB first came out, right? Same thing.
ADRIANA: Yeah
TIM: It was just a fork of MySQL, right?
ADRIANA: Yeah
TIM: You look at the same thing with Java.
ADRIANA: Yes!
TIM: You know, when...whenever a company's been like, okay, cool, we're going to commercialize this thing, and the open source companies be like, I don't think so. I don't think we're going to do that. Before this, it was with Elastic and Amazon with...
ADRIANA: Oh yeah, that's right!
TIM: ...with OpenSearch, which I really think... now, I'm going to be honest, I know the inside because I used to work for Elastic and I've heard Shay talk at great length sometimes about kind of what his view on that was. And companies owning an open source product is an oxymoron, right? Open source, the community owns it, right.
ADRIANA: Yeah, absolutely.
TIM: And if you want to dip into that well to make some money, that's fine. Everyone else can too, right? If a company owns it, it's not open source.
ADRIANA: That's true.
TIM: I mean, they have the ultimate control over it in the end, right?
ADRIANA: Yeah.
TIM: And we're seeing that over and over again. It's like companies, instead of going through and developing products and service around products and services around this product that make people want to spend money on it, right. They're seeing competition getting upset, and they're trying to stifle competition rather than just getting better at it.
ADRIANA: Yeah, yeah, that's true. It's interesting because it makes me think of OpenTelemetry, which is open source, and before, in the Observability world, everyone had their own tracing implementation. Right? And then OpenTelemetry is like, no, let's standardize it. Right?
TIM: Yeah.
ADRIANA: The cool thing about it is all of the major Observability vendors are fully supporting it, and so you have the community coming together to support this thing, and so what differentiates the vendors is not their proprietary SDKs. It's, how do they render the data? So it changes the conversation, which I think is, like, really cool.
TIM: And that's the way it should be. Right? I want to choose a company that offers this service based on the quality of the service, right? Whether it's faster, whether it's more reliable, whether I get better support if I've got these people that do, like, hey, I used to work as a MongoDB, as a service provider, right? And we competed directly with MongoDB Atlas. We competed with AWS to some extent, things like that. I was like, we were just better at it. That was all it was. We were just better at it. Right? And that was fine.
But the other thing, too, is..."Better at it." Does that mean that we have enough? Are we essentially like a lifestyle business, or are we trying to make billions of coin, the market, blah, blah, blah? And so I think that's, too, it's like, what is your end goal? Like, there's always this thing. Well, you have to be the biggest and baddest thing. It's like that late stage capitalism thing. No, actually, I'm cool with only owning, like, 20% of the market I'm cool with only owning 10% of the market as long as me and all my employees get paid, right? And customers happy and we do kind of organic growth, that's fine. I don't understand whatever happened to just kind of growing normally and organically? That being okay. Right? We make a profit, people get paid. People can go on vacations. Everyone should be...I don't understand why that was never good enough, right. Or was good enough. And now it's not.
But what you end up happening is you have a crush and a grind to get some stuff out, some innovation happens, and as soon as people start trying to return money to investors or go to IPO, now it's the same standard playbook like everyone does. Okay, great. Now we're going to do this, and we're going to do this. We're going to do this. And you see it over and over again. And so all the promise that you see behind a company or a product that gets you excited, you already know that the shoe is going to drop and get short-lived, and now they're going to add like, they're going to ruin it.
ADRIANA: Yeah...
TIM: Do you remember WinAmp?
ADRIANA: Yeah, I do!
TIM: Right? WinAmp was great, right? WinAmp, I think it was, like, 2.54. It was like, the thing. It was so amazing.
ADRIANA: Yeah.
TIM: And do you know what happened to WinAmp?
ADRIANA: I don't...no...
TIM: They got bought by AOL.
ADRIANA: Oh...
TIM: and AOL ruined WinAmp.
ADRIANA: Oh, jeez.
TIM: Yeah, it was awful. I will never forgive them for that. They ruined WinAmp.
ADRIANA: Oh, jeez.
TIM: Uh, do you remember ICQ?
ADRIANA: Yeah, absolutely.
TIM: ICQ was great. It is still, to this day, my favorite messaging platform. You know what happened to ICQ?
ADRIANA: I don't, no.
TIM: They got bought by AOL
ADRIANA: Get out of town. I did not know that.
TIM: Yeah, AOL ruined ICQ. Right?
ADRIANA: Oh, man.
TIM: Do we see this trend, like, what's happening? A pattern. When we talk about this thing of, we're going to buy this thing and then stops. Do you remember HipChat?
ADRIANA: Yeah, I vaguely remember it. I never used it, but I do remember it. Yeah.
TIM: And it was kind of cool.
ADRIANA: I never use it, but I do remember it. Yeah.
TIM: It was kind of fun. And then it got bought. I think it was either Slack bought it from Atlassian and then shut it down.
ADRIANA: Interesting. Oh, shoot.
TIM: And so when we start seeing this kind of thing where we're like, oh, well, we don't actually want to build a better product, right? We want to eliminate people's ability to choose between products, right? So we don't want to actually have to compete because that's too expensive, right? So it's just cheaper to buy them out. And then not have to make something better, right?
ADRIANA: Yeah.
TIM: And so that kind of thing is like, I don't like that. Let the community decide if your product is better. Great. People will use it. They'll buy it, right? Or if there's more of a compelling reason for them to use it. If it's less expensive, if it...service is better if it's just more available, whatever it is, right? Let people choose that, right?
ADRIANA: Yeah, absolutely.
TIM: Don't kill the competition with a pen and lawyers. Kill the competition by building a better product.
ADRIANA: Yeah, I totally agree. I totally agree. Yeah. It makes me think of Oracle as well. I spent many years as a Java developer, and so in my Java days, like, the Java app server, my favorite one was, like, BEA WebLogic, and I think Oracle bought them in and was like,
TIM: But so many things that we enjoyed have been ruined by acquisition, right?
ADRIANA: Yeah, it's super sad.
TIM: So when we see this trend continuing through stuff that was used and or beloved by the open source community, it's just more things like, we can't trust corporate interests to have our best interests in mind, because they don't. What's good for the corporation is almost never good for the customer.
ADRIANA: Oh, definitely not. Definitely not. Yeah, I feel the same way. I think that's one of the things that frustrated me when I started working was realizing, like, the world is more nefarious than I would like it to be. I'm like, Why can't we all just be friends?
TIM: But I think what's worse than that is that there's also the narrative by some straight white dudes on Twitter who are like, oh, well, you're a highly paid capitalist person. You can't be against capitalism. I'm like, just because I detest the system doesn't mean that I'm not good at it, right? Matter of fact, because I'm good at it is why I detest it, right? I'm coming from a place where I know how it works and I know how to make it work for me, and it's terrible.
ADRIANA: Yeah
TIM: I shouldn't have to, right? That's not hypocrisy, that's understanding.
ADRIANA: True. Yeah, I totally agree with you.
TIM: But I'm not going to mention any names, who it is. They know who they are, and they're probably listening to this.
ADRIANA: Now, pivoting...I want to pivot back to a thing that you said earlier when we were talking, when we were doing the rapid fire questions, the Dev versus Ops. You said you had opinions, so I want to hear them.
TIM: Yeah. So here's the thing, right? There has been this long, probably a good ten years worth, if not longer... But I know for ten years at least, move to minimize the role of Ops in what we do for software and product delivery, right?
ADRIANA: Yeah.
TIM: There's DevOps. And they're wrong by thinking this, but a lot of folks think like, oh, it's when dev people do Ops or Ops things gets automated, right? That's not what DevOps is, right? Remember the NoOps push for a while?
ADRIANA: Oh, God.
TIM: Like, oh, we don't need Ops.
ADRIANA: It's like no code. Like, yeah, right.
TIM: Yeah. What they're saying is we're abstracting the work of operations away so that devs don't have to be concerned with it, so that they can just do on development. And a lot of developers think that the sun rises and sets by whatever they type out of their fingers and it doesn't, right? The realty is that developers are a skill, don't get me wrong. It's skilled and very difficult. Not very difficult because it's not like any of us are doing brain surgery, right? It is a skilled and it is a highly complex skill set, right? But it is only a piece in the cog, right?
And developers are not rock stars, right? They're not. I don't care. The notion of a 10x developer is bullshit, right? You can have all the developers in the world you want to, and you're just going to be developing...you're going to be running stuff on your laptop if it's not for operations, right? Everything happens because of operations, right? And we rely on each other. Like operations need developers to write software for them, they need developers to write drivers, they need developers to write firmware. Like all that kind of has stuff, like APIs, like that also has to work.
But when you need stuff to work and you want to make money, it's your operations and support teams that actually do that, right? Developers will get you sales, operations will get you renewals.
ADRIANA: Yeah, that's actually a really good point.
TIM: And what does any business want more than sales? They want renewals. Let's talk about get renewals from Ops, right? But I think, I think where we come where we come off the rails in a lot of this is like, what are our roles? We're developer relations roles, right? I work for a hardware manufacturer. We don't you know, I should be talking to operations, right? If if you do any kind of API for hardware, stuff like that, you should be talking to operations folks. Unless you're selling specific developer tools, then you should be talking to devs. If you're selling things that people consume in their operations, especially anything around infrastructure or networking, you should probably talk to operations too, right? But we focus on developers, especially when it comes to salaries and stuff like that, because we're thinking, oh, well, operations can be obfuscated away and do this and this and this and this, right?
But the operations knowledge gets more and more complex, like how many Ops folks when people talk about using Kubernetes as we abstract away more stuff or like platform engineers like that, they're just operations folks, right?
ADRIANA: Yeah, absolutely.
TIM: We're providing a platform for developers to use because we do not want them interacting with the hardware, you know?
ADRIANA: Yeah, yeah. Sorry. Go ahead.
TIM: And so, and as it so there's this...they change the name for operations over and over again, right?
ADRIANA: So true.
TIM: Because they don't want to just come out and say like, hey, these are Ops folks.
ADRIANA: Yeah. I completely agree with you. And it makes me think of something. And to your point, operations folks have been tasked with learning more and more and more stuff, right? Like, picking up managing Kubernetes clusters, and learning these IAC tools and like, you know...
TIM: Managing Docker repositories and then CI/CD tools and stuff like that. People who are called DevOps engineers, they're just Ops folks, but they're working on the internal tooling, right? That's all it is, right? But it's funny because really, ideally in the pie in the sky world, the very last concern that a dev is going to have is like, okay, I am now going to package this thing up. That's where it should end. And maybe not even that. I'm just going to commit it to main, right? I'm going to commit it to the production repo. That's where I want you to stop, right? Cool. We've got it the rest of the way, right?
Once it gets committed to production, to the production repo, everything else is operations at that point, right? And that's kind of how it should be. I don't want the developers to have to work and not that they can't. I just don't want them to have to I want you to just go back to developing, fixing bugs, developing features, right? Operations has the rest.
ADRIANA: Yeah. Now, do you think, though, that it's helpful to have that mutual empathy for what each of these roles entails? Right? Because I do feel like maybe there is this us versus them mentality with Devs versus Ops, and I've been on both sides of it, and I feel like especially when it comes to developers are done developing their feature, throw it over the wall, it's gone into production. That's it. And now there is a bug that arises, like, not my problem.
TIM: So I think that's the whole thing that DevOps is supposed to be solving, right?
ADRIANA: Yeah, supposed to be...
TIM: The throat of the wall, the silent isolation it's supposed to be solving, like they turn into all these other things, and it's not.
ADRIANA: Yeah, absolutely.
TIM: DevOps is a culture, right? A culture of collaboration and interoperation, right? Where Ops has these levels, concerns and the roles and things they got to do great. It should be informed by what devs do. Devs should be informed by what Ops do. Ops should be able to say like, hey, these are things we found has this problem, this problem, this problem, this problem. So you need to work that into your dev cycle to get these things fixed because these are not operations issues. These are like software bugs or whatever. Right? Cool. That's great. Dev should be able to say like, hey, it's supposed to do this and this and this and this. So when you're designing architecture reviews like that, you have to make sure this and this, it is going to rely heavy on this caching thing. So you have to make sure it's robust. Those are the things that Ops folks should be concerned about with that. Right?
I think what ends up happening, and this is just my observation as an Ops person, that Dev has very little knowledge or concern about what happens in Ops. Right. But Ops, by the nature of the role, has to be concerned about the code that's coming out that they have to deploy. Right? And I think to the extent where Devs do not concern themselves with Ops and they think that the whole world revolves around them, that poisons the culture.
ADRIANA: Yeah. Absolutely.
TIM: And then you end up developing kind of practices around that notion where Dev is the most important thing. Right, but the customers don't interact with the Devs.
ADRIANA: No, they don't.
TIM: Customers interact with Ops.
ADRIANA: Yep, yep.
TIM: And that goes back to what I said before about customer-driven development and having context for the things you do.
ADRIANA: Yeah, absolutely.
TIM: Right, but in the end, I think what's so interesting about that is that we have to have this kind of cultural coming to Jesus moment. But also that's an organizational thing because not all organizations are like that, but a lot of them have come that way and that's where the leadership comes in. Right, but we're not doing leadership, we're doing management. Those aren't the same thing.
ADRIANA: And that's where I think having those honest conversations that so many organizations lack becomes a problem as well. Right? You've got people not wanting to admit when there's a problem, people being basically creating their own kingdoms and wanting to protect their own kingdoms and not thinking outside the kingdom. You launch into those sociotechnical issues that plague so many organizations. I definitely see that a lot in big organizations, but it doesn't mean that the small organizations aren't immune to them either. I mean, that can easily happen.
TIM: I think that's kind of what you talk about. It's like you talk about how do we do these things? We've created so much tooling and so many products so that we don't actually have to talk one with another, right?
ADRIANA: Yes.
TIM: So that we try to automate, not even automate empathy. We're just kind of like, oh, we don't need emotions or empathy about this because it's not about the people. So it's like Slack. Why do we have Slack? Because we don't really want to talk to people, we want to be able to chat with them. Right? Why do we have GitHub issues where we interact with people, like over text? But a lot of times too, if you just...not that you can't do this in remote culture, but just like we're doing like, hey man, let's pop into a Zoom meeting for five minutes and we'll talk about this thing. Great. All done. Right.
ADRIANA: Yeah.
TIM: And yes, I understand the large distributed teams where asynchronous communication is very important, you have to be able to communicate that way, to collaborate. And that's fine. But you understand it's going to be slower, right.
ADRIANA: Absolutely.
TIM: But if you want to quickly, let's have a conversation. We can understand each other, have some and then I can understand your side better. Or what? Your...not even your side. I can understand what your concerns are better. Right? And have context for why you're saying the things that you're saying or why you have the concerns that you have. And now they can become my concerns, or I can address the concerns that you have a little bit better.
ADRIANA: Yeah.
TIM: Right, but we have so many tools so that we don't have to do that's.
ADRIANA: So true. And I think part of it, too, is people are afraid of confrontation. Like, it's easy to hide behind a chat window, right? But as soon as you're face-to-face with someone, it's it's easier to hate someone or what they're doing behind the chat window. And then the face-to-face is like, there's a person.
TIM: Well, I think it's weird because some people rely on other people. Like, that the stereotype of that one asshole engineer that always makes it hard for everybody else. It's a stereotype because it was very often true in a lot of orgs, right? They're relying on getting their way because people don't want to have arguments or confrontation or whatever. Right? And it doesn't have to be about that. It's like, hey, man, you actually don't have that much power. You can argue about all you want to, but once we go for this peer review...in that way, it's good.
Right, but at the same time, it's like, if you have to do that just to deal with this one person, how about we just get rid of that one person who doesn't know how to be empathetic and work on a team? Doesn't matter how good he codes, if we have to implement all these things just for this one person.
ADRIANA: Absolutely.
TIM: You should have organizational fixes, but also you can get rid of toxic people in your org.
ADRIANA: Yeah. And that's an interesting point because I think there's this mentality in a lot of teams where, like, oh, but this person is a superstar. We can't possibly get rid of them, but they're fucking with the team's mojo, and that can be worse than having this superstar who knows their shit and fixes things and blah, blah, blah. Because now you're affecting the morale of your other folks, and then that can create tension in-fighting whatever. Right?
TIM: Yeah. And we see this like...I'm going to draw a parallel to sports teams. You've seen sports teams that have one superstar player and the rest team is garbage. Right? Or even if they're not garbage, that one superstar player is a problem and it causes discord on the team. Right? They're a problem in the locker room...
ADRIANA: Absoluelty
TIM: ...they're a problem with the whole thing. They get so much attention. Negative attention. Right? That the rest of the team falls apart.
ADRIANA: Yeah.
TIM: And as soon as they get rid of that one person, they're great. Right? But you can have a superstar player that makes other people around them better. Right? You look at like, Michael Jordan, right?
ADRIANA: Absolutely.
TIM: One of the great examples. Was he a jerk? Yeah. Was he good? Yeah. But did he make other people around him better? Absolutely. Right. And like, that's what you want. You don't want to have somebody who's just, well, this person knows this one technology really great. You know what, I can deal without that. I don't have to have that. If you have to have that, that's a business failureship. That's a leadership failure. Failureship. Failureship.
ADRIANA: Yeah.
TIM: That's a leadership failure.
ADRIANA: I absolutely agree. I think it all boils down to just focusing on the human aspect of...we are humans working with other humans. And we should not forget that. Like, we do not work with robots. Not yet. Maybe someday. Sorry.
TIM: So we work on robots, right?
ADRIANA: We work on robots. Exactly. Perfect. Yeah.
TIM: But technology is inherently still about people. People consume it. People need it. They have needs that they want to address, right? We're basically using these things to solve problems, right? But again, technology for the sake of technology is just masturbation, right? We need to be able to have interoperations of team. We are software engineering teams. We are operations teams. Company is a team, not a family, right? We're a team. And so we have to interoperate.
And it's so funny because if you think I'm going to go back to a sports reference for those, you know, it's like everyone on the a lot of people will make fun of the kicker until that kicker needs to save the game, right? And then all of a sudden the kicker is the hero, right?
ADRIANA: Yeah.
TIM: There are no unimportant parts of a team, right?
ADRIANA: Yeah...
TIM: People like, "Who's the long snapper?" People know who the star quarterback is, but they don't know who the long snapper is. But the long snapper can lose a game for you. You know what I mean? That's an important thing to remember. The team exists with all the people in it. It's not all about one person. Everybody on that team is necessary and important
ADRIANA: Yeah.
TIM: whether or not they are rock stars. And then you can extend that beyond just a single team and talk about the interoperability of various teams in an organization like you're. We're about to have some fucking tea right here, my friend. Do you know how sick I am of mostly developers I'm going to go back to that again who are very self-righteous and very degrading to people who are quote unquote, non tech roles like HR, like sales, like customer success.
All these people like that. They are why you have a job because of them. I may not agree with having sales pressures, but I will never say we don't need salespeople, right? Because somebody's got to talk to these people because you can't you're not good at that.
ADRIANA: That is so true.
TIM: That's not your role, right?
ADRIANA: So true.
TIM: You need to be understand some of these pressures. You need to be able to interface with people of various roles and really go out there and put yourself on the line, right? You have to be able to make sure that we all get paid.
You have to make sure that we all have insurance and make sure that we get people in here hired. You have to make sure that your video conferencing stuff works, that you're laptop works.Like all these things are not we don't have anybody that we're not going to say not anybody. For the most part, people are working there because their role is necessary, right?
ADRIANA: Yep, absolutely. Things don't happen by magic and fairies.
TIM: When people say, oh, the Rockstar, you know what, I've had Rockstar office managers that they paid six figures and absolutely they were worth every penny because they made the stuff happen, right? Yeah, absolutely. I've had Rockstar recruiters everybody at a company. Their role should be important and should be necessary, right? Even if they're the long snapper or the punter.
ADRIANA: The yeah, totally. I love that so much. Well, we are coming up on time, but before we finish off and you've given us so many awesome hot takes, but do you have any final hot takes to impart or pieces of advice?
TIM: Honestly, the final hot take and piece of advice that I want to impart is to stop having sales-driven development, right? We talked about resume-driven development. We make things overly complex and complicated just because because so and so...and we shouldn't have that but we also shouldn't have development based around a sales quota or based around anything like that. Like, no, man, make the product. Make the product good.
ADRIANA: Yeah.
TIM: Make the product something that people want to use. Right. And then we'll get it sold. Right.
ADRIANA: Totally.
TIM: But don't go chasing waterfalls. Just stick to the rivers and the lakes that you're used to.
ADRIANA: I love it. I love it. Thank you, Tim, so much for geeking out with me today. And y'all, don't forget to subscribe.
TIM: My pleasure.
ADRIANA: And be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time...
TIM: Peace out and geek out.
ADRIANA: Geeking out is hosted and produced by me, Adriana Vilella. I also compose and perform the theme music on my trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the Socials by going to bento.me/geekingout.
ADRIANA: Hey, y'all! Welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela, coming to you from Toronto, Canada.
And geeking out with me today is Tim Banks. Welcome, Tim.
TIM: Hey. How's it going, Adriana?
ADRIANA: Good. And where are you calling from today, Tim?
TIM: I am calling from the balmy summer capital of Austin, Texas, where it's been over 100 degrees for 40 somewhat days straight.
ADRIANA: Wow, that is very hot. I am definitely like a tropical gal, but I don't know if I could do 40 degrees over 100 degrees, which I guess is like 40 degrees Celsius for that many days straight. It's a lot. Ouchy. Ouch. Well, stay cool. I hope.
TIM: Yeah. Literally, right off camera, I've got my Govee stick fan. Literally, I'm touching it right now, so I have it strategically positioned.
ADRIANA: That's awesome. Yeah, nothing like a good fan to help cool off. Yeah, I have one in my office in the summer because it gets like, so hot.
TIM: Yeah. I face the window, which is great for the lighting, but also then it gets, like, hot in here, so...
ADRIANA: I know, right? Yeah, I have the same problem. All right, well, let's get started with some lightning round questions. All right. I swear they won't hurt. Okay, question number one. Are you a lefty or a righty?
TIM: I'm left-handed...
ADRIANA: Yay.
TIM: but because my dad taught me how to do, like, most sports things, so I throw right handed.
ADRIANA: Oh, interesting. That's pretty cool. Yeah, it's funny, there's like, certain things where I think I'm a lefty as well, but I do certain things right-handed. Like, I could not even fathom using a mouse left-handed. That just feels super weird to me.
TIM: Yeah, it does.
ADRIANA: But I know some left-handed people who are like, yeah, I mouse left-handed.
TIM: Yeah. I've switched around. I'm like, that's just weird to me. Right? Same.
ADRIANA: Yeah. Also my check marks are right-handed people checkmarks. My mom, who was left-handed, did the left-handed people checkmarks, which were backwards or mirror images?
TIM: Yeah, I know. Yeah. It's a pull instead of a push. I still do the push on the check mark, too, because just because.
ADRIANA: Yeah, which makes sense because of being left handed, but I think it was like, that conditioning. So anywho yeah, cool. Okay, next question. iPhone or Android?
TIM: Oh. iPhone. All day long. All day long. I make good tech money. I don't need a Walmart phone.
ADRIANA: Love it. Okay, next one. Mac, Linux or Windows?
TIM: Depends on what I'm doing. Windows is never the answer, but I have to use it if I'm gaming. Fortunately, I'm not a PC gamer. I use consoles, so pretty much Mac most of the time. But if I'm doing running a server or something like that, it's going to be Linux.
ADRIANA: Fair enough, fair enough. All right, next one. Favorite programming language?
TIM: Python
ADRIANA: Me too. I love Python. Okay.
TIM: It used to be Perl, but then Perl just gets really difficult to read after a while, and I don't have that kind of time anymore.
ADRIANA: I've never done Perl, but my job before the current one, they had a lot of Perl and I'm like, damn. I'm not going to lie.
TIM: Perl powered Web 1.0. Right? If we're going to be honest, all the cool stuff was done in Perl a little bit. There are some other Johnny-come-lately languages that really got into the later version of the web. But your original cgi-bin stuff, like all the cool stuff yeah. All Perl. That was all Pearl, man. You get it?
ADRIANA: I rember that. I never got into Perl, but yeah, that's what I remember it from.
TIM: I'm like anyone doing the complex web stuff back in the day was like, it was Perl. Yeah, it's all Pearl.
ADRIANA: That's cool. Okay, next question. Dev or Ops?
TIM: Oh. Ops. All day long, Ops makes things happen. Look, here's my take on it, and it's going to be spicy, and I don't care, but...
ADRIANA: That's awesome.
TIM: ...devs are worried about being replaced by AI. Ops is not.
ADRIANA: Interesting. I feel like we need to dig into that one a little bit later.
TIM: Mm hmm. Oh, we can. We can. I have opinions.
ADRIANA: Very intrigued. Next one. JSON or YAML.
TIM: JSON.
ADRIANA: All right, next one. Do you prefer to consume contents through video or text?
TIM: Depends on the content. Right?
ADRIANA: Mmmm!
TIM: I don't typically like video shorts, so I like little microblogs, but anything of any substance, I like in video because I throw on a video essay and just kind of do whatever. Text is fast. If I want to consume it fast, it's text. If it's going to be anything longer, it's going to be video.
ADRIANA: Yeah, that makes sense. And then final question. I just added this one on, which I actually like to ask in interviews. What is your superpower?
TIM: Oh, gosh, that's a hard one. So my superpower is understanding people...I think that is a good superpower...kind of digging in and getting behind the eyes a little bit on them and figuring out what's going on. That makes a lot of sense. And I feel like it fits in with the DevRel life because we have as much tech in our work as we do, like, the people side of things. Yeah. Understand. Understanding. Not like I use this, but like, okay, but what are you really trying to do? Right? What is this thing trying to make you help? What is keeping you up at night that this will keep you from keeping keep you from keeping up at night? I guess maybe.
ADRIANA: Yeah, that makes a lot of sense. Absolutely. And it's funny because it makes me think of so many times at work where people will come to me and they're like, I need X, and then so I think the gut reaction for a lot of people is like, okay, let's make that happen. But one thing that I've learned over the years is like, but why do you need X? What are you actually trying to do so that you have that extra bit of context? Because maybe you don't need X, maybe you need Y.
TIM: So I think the main problem that I've found in software development cycles is that we are so removed from what the customer actually needs and wants.
ADRIANA: Right.
TIM: Because you think about the customer, how many people that a customer talks to before you actually get to the thing where you're going to develop the thing that you think they're asking for. Right? They're going to talk to a salesperson, they're going to talk to a CSM, they're going to talk to a TAM, they're going to talk to a DevRel. Right? Maybe they talk to company leadership. Right? That gets distilled down and fed to a product manager, who's going to distill something down and feed it to a project manager, who's going to make requirements that you as a developer are going to then try to accomplish. Right. But you don't actually know what the customer is trying to do. And without that context, you're flying in the dark. I've often said that development without context is just masturbation. Right? Because you're doing the thing that you think is right. It makes me feel good, but I don't know if actually no, if it's accomplishing what the other person needs.
ADRIANA: Yeah, that's absolutely true. And it's interesting because I think as much as I get annoyed by Agile, I think it tries to bridge that gap a little bit more by getting the right people talking to each other versus the old ways of Waterfall, where I worked at a bank for eleven years and the developers were so far removed from the business people. We had the business people, then we had the business BAs and then we had the technical BAs and then we had the developers and it's like, what the hell?
TIM: It...honestly, though, I still feel like Agile and the Sprint system still operates without a lot of context. Right.
ADRIANA: Yeah, yeah.
TIM: Because we're taking most of our cues from sales, if we're being honest. Right. And that's why I think DevRel is really important because we're the ones that talk to the users and the customers and the community. Right? And so the DevRel should be an engineering role more than anything else because we should be talking directly to product. Product should be talking to us. We should be talking to the engineers. We should be connecting engineers to the people. Like, yes, I love to go up there and give. Well, I don't actually don't love giving. I actually love talking. I love going there, being on panels and stuff like that. But really, who should be at the booths is not DevRel folks. It shouldn't be salespeople. It should be the engineers who are working on the product and the product managers like that. They're the ones that should be talking to the community and to the customers and the users, not salespeople. I mean, yes, your DevRel folks also, but we're going to do that anyways. Right, but if I want to make the most out of an in-person function, I want the people who are building the things that we're selling interacting with the community as much as possible, not the people who are selling. Right? Salespeople at a conference is really not it. It's not it, you know what I'm saying?
ADRIANA: Yeah. I know what you mean.
TIM: When you walk down to a big city and you go past a place and people are barking at you to buy this thing from the thing that you're really not interested in, that's what that is at a conference. And it's not cool.
ADRIANA: Oh my god, that's so true. It's so true. Yeah. And it's interesting because you seldom ever see at conferences...like, the engineers attending. Every so often you will get that, but especially like at a startup where everyone does everything...but at the larger companies you're absolutely right that you see mostly the DevRels or the sales folks at the booth.
TIM: And so we need to fix that. Companies like, well, we can only send, like, however many people I'm like, you can send more. You just don't want to, first and foremost. And it's like, you don't need to send salespeople, right? They're going to get the leads from the thing anyways. Right.
ADRIANA: Yeah, absolutely
TIM: That's all well and good, the leads that no one's going to respond to. Right. But if you really want to take advantage of being in proximity to the people that use your products or who could potentially use your products, it's the people that build it.
ADRIANA: Yeah, it's so true. And it makes a deeper connection because I remember I've worked the booth before doing lhe lead-generation. Like, oh, let me scan your badge. And it's a very impersonal thing. And then when you have your badge scanned, and then you go back to the office after a conference and you're getting all this bullshit spam email, and you're like, oh, my God, just stop. It's irritating. I don't want to talk to you. I'm going to unsubscribe from your list ASAP. Like go away.
TIM: Or they give you the drip campaign, which I hey, I know we just talked, like, the four or five replies. I'm like, Bro, I have not replied yet to you, so I'm not sure why you keep emailing me, but it's a sales thing. It's like this thing they teach you... oh, you just keep reaching out. Like, no, man. I don't know why this became a thing. You know who I want to talk to? I don't want to talk to those salespeople, right? If you want to intrigue me on something, let me talk to the person who built it.
ADRIANA: Yeah it's so true, it's so true. Talk to the real geeks out there.
TIM: I think where we come off the rails and a lot of that development, like I said, is just we operate without context or we think we did something great, this innovative thing, and then the customers are like, yeah, it's not that I want to actually use that thing. It's not that great, or what's going to make the biggest impact. I would have much rather you did this, right? Because we prioritize a feature based on sometimes a specific sale or two or three customers, right? Because it's big numbers right away for these two or three customers. But you could have much bigger numbers if you met the needs of a lot of customers with a feature or with a fix, and then they grow in your product. Right. I don't need to sell a million dollars next quarter. Or what I need to do is I need to sell $20 million over the next three quarters.
ADRIANA: I remember I've worked with previous jobs with vendors where they're obviously a small startup and we're obviously their big client. And so they are bending over backwards to get your business and putting certain feature requests on hold for your feature request because you are the big screaming client, which ends up being a detriment to...
TIM: Always, always.
ADRIANA: the company I think, as a whole.
TIM: Because you have that one customer you cannot lose.
ADRIANA: Right, yeah, exactly.
TIM: And that is a growing pain, because you have now stopped being a company and now you're a contractor.
ADRIANA: Yeah.
TIM: You're pretty much held hostage by this one client and you have to bend to their will which is a very uncomfortable place to be in. There is this kind of bravery, I would say, almost, that comes...it's actually called leadership...that comes with saying, like, hey, no, this is the vision. We're going to actually develop the product to meet the needs of these customers. If you want it, great. You can buy it. That's awesome. If you don't like it, I want to know why you don't like it, right? And then maybe we can fix it. But also, I'm not going to bend over backwards just for you to the detriment of everything else. Right?
ADRIANA: Yeah, absolutely, absolutely.
TIM: And so I think the weird part is that people are like, there's a thing that you have to pursue this right now. We need this right now. We read this right now and a lot of people are playing checkers and we need to be playing chess.
ADRIANA: Yeah. I love the prop.
TIM: I don't know if this is going to be video or audio or not.
ADRIANA: It's going to be both, actually So the people that watch this will enjoy the clack fan. I am so happy you brought out the fan actually.
TIM: I actually have one that says shade on it, but I left that in the other room. So you just get the rainbow fan. But the point still stands.
ADRIANA: Absolutely. But it's interesting on that same point. I think it also brings to mind this whole mentality, especially in corporations. And I think you see this the larger the corporation, where people stop having honest conversations with each other. You're so hell bent on not disrupting the hierarchy and like, oh you went over someone's head. Or people are afraid of owning up to their mistakes because of whatever, makes it very hard to be productive.
TIM: There is this...almost politician-like cop-ing out on accountability.
ADRIANA: Yes.
TIM: No one ever wants to admit a mistake, or no one really wants to admit the true reason behind something, which is just, I want to make money, right?
ADRIANA: Exactly.
TIM: Let's take HashiCorp, for example, right? They come in here with this, oh, we're protecting open source. And by doing this and people doing this and not contributing...like, no, bro, you had an awful quarter and you're trying to make investors happy. You can just...just say that I would have much more appreciated that than feeding me copious amounts of bullshit about the open source community that you just hung out to dry, right? And in the end, it's going to cost you in the long run. I don't know about a career limiting decision, obviously, but it's certainly going to be a scope-of-influence-limiting decision for HashiCorp over the long run. Right? But they were thinking about this quarter and next quarter, right?
ADRIANA: Yeah.
TIM: And I'm sure it's going to make some investors are going to be like, okay, great, they're doing something great, but it's not going to be good in the long run. The community is already looking at this and going, all right, well, it's a mistake to rely on a single company for this, so let's either look for an open foundation or do we even need this at all?
ADRIANA: Yeah.
TIM: Think about it. When Terraform first came out, there wasn't really a good, strong API for interacting with a lot of the ways we consume hardware and infrastructure resources, right? So Terraform is very useful to have something, especially as an alternate to Puppet, right, because it was open source and much more usable and much more elastic, I guess, in those ways, keeping state and being able to compare things like that, committing things to GitHub, etc. etc., right? That's not the case anymore, right? You can have programmatic access to hardware and infrastructure provisioning APIs and health checks, and state have whether you've got CDK and CloudFormation AWS, Google's got whatever it's got. I'm sure Azure's got some VBasic scripts or something like that you can run. I'm kidding. I'm just throwing shade, Azure.
But the thing you really have to ask is now, do we need to have another entire product for infrastructure-as-code, which is what it comes down to, or can we now use the native tools and native APIs we have and store state somewhere else? The answer is yes, there are open source alternatives to doing exactly that. And we were never really forced to examine our need for it until Terraform said, ha, we're going to change the license. Right? And then now people can just decide to make you irrelevant, which never would have happened if they had done this. People were just happy on like, okay, cool, we'll keep using Terraform because there's no reason to examine it. Now they have.
ADRIANA: Yeah, it's true. And it's interesting because Hashi fans are like, there are hardcore Hashi fans out there, and I do feel like it alienates a lot of them.
TIM: It does. And I think the interesting part is that the people who are Hashi fans now, where is your allegiance? Is your allegiance to the company or the product?
ADRIANA: Yes, yes...
TIM: And those are two different things now, right?
ADRIANA: Absolutely.
TIM: Or they were two different things and now they're the same.
ADRIANA: Yeah, it definitely brings that more to the forefront, as a result.
TIM: The...you know, you got a lot of discourse, you know, especially people like Kelsey who are saying, really talking about what does it mean to have open source maintenance, or how do companies, large corporations with capitalistic interests, what influence do they really have on these things? Or how should they be allowed to participate in these open source projects in ways that don't hurt the community, right? And so you really do have to kind of ask it's like, what do we as a community of practitioners and users and influencers and decision makers and things like that, what are we going to do to really change this going forward? Right? And we do have the ability to influence that. We can change that. It's just a matter of are we going to, we're going to dedicate the time and energy to it or are we going to abstract it away like we tend to want to do with everything else?
ADRIANA: Yeah, absolutely, or it could be that someone gets pissed off enough, and then... what was the...I want to say there was, like, MySQL that they closed sourced, and then they forked it off to an open source version. Am I getting that right?
TIM: Yeah, that was right. Oracle got it and did all that. And then well, I think first it was like when MariaDB first came out, right? Same thing.
ADRIANA: Yeah
TIM: It was just a fork of MySQL, right?
ADRIANA: Yeah
TIM: You look at the same thing with Java.
ADRIANA: Yes!
TIM: You know, when...whenever a company's been like, okay, cool, we're going to commercialize this thing, and the open source companies be like, I don't think so. I don't think we're going to do that. Before this, it was with Elastic and Amazon with...
ADRIANA: Oh yeah, that's right!
TIM: ...with OpenSearch, which I really think... now, I'm going to be honest, I know the inside because I used to work for Elastic and I've heard Shay talk at great length sometimes about kind of what his view on that was. And companies owning an open source product is an oxymoron, right? Open source, the community owns it, right.
ADRIANA: Yeah, absolutely.
TIM: And if you want to dip into that well to make some money, that's fine. Everyone else can too, right? If a company owns it, it's not open source.
ADRIANA: That's true.
TIM: I mean, they have the ultimate control over it in the end, right?
ADRIANA: Yeah.
TIM: And we're seeing that over and over again. It's like companies, instead of going through and developing products and service around products and services around this product that make people want to spend money on it, right. They're seeing competition getting upset, and they're trying to stifle competition rather than just getting better at it.
ADRIANA: Yeah, yeah, that's true. It's interesting because it makes me think of OpenTelemetry, which is open source, and before, in the Observability world, everyone had their own tracing implementation. Right? And then OpenTelemetry is like, no, let's standardize it. Right?
TIM: Yeah.
ADRIANA: The cool thing about it is all of the major Observability vendors are fully supporting it, and so you have the community coming together to support this thing, and so what differentiates the vendors is not their proprietary SDKs. It's, how do they render the data? So it changes the conversation, which I think is, like, really cool.
TIM: And that's the way it should be. Right? I want to choose a company that offers this service based on the quality of the service, right? Whether it's faster, whether it's more reliable, whether I get better support if I've got these people that do, like, hey, I used to work as a MongoDB, as a service provider, right? And we competed directly with MongoDB Atlas. We competed with AWS to some extent, things like that. I was like, we were just better at it. That was all it was. We were just better at it. Right? And that was fine.
But the other thing, too, is..."Better at it." Does that mean that we have enough? Are we essentially like a lifestyle business, or are we trying to make billions of coin, the market, blah, blah, blah? And so I think that's, too, it's like, what is your end goal? Like, there's always this thing. Well, you have to be the biggest and baddest thing. It's like that late stage capitalism thing. No, actually, I'm cool with only owning, like, 20% of the market I'm cool with only owning 10% of the market as long as me and all my employees get paid, right? And customers happy and we do kind of organic growth, that's fine. I don't understand whatever happened to just kind of growing normally and organically? That being okay. Right? We make a profit, people get paid. People can go on vacations. Everyone should be...I don't understand why that was never good enough, right. Or was good enough. And now it's not.
But what you end up happening is you have a crush and a grind to get some stuff out, some innovation happens, and as soon as people start trying to return money to investors or go to IPO, now it's the same standard playbook like everyone does. Okay, great. Now we're going to do this, and we're going to do this. We're going to do this. And you see it over and over again. And so all the promise that you see behind a company or a product that gets you excited, you already know that the shoe is going to drop and get short-lived, and now they're going to add like, they're going to ruin it.
ADRIANA: Yeah...
TIM: Do you remember WinAmp?
ADRIANA: Yeah, I do!
TIM: Right? WinAmp was great, right? WinAmp, I think it was, like, 2.54. It was like, the thing. It was so amazing.
ADRIANA: Yeah.
TIM: And do you know what happened to WinAmp?
ADRIANA: I don't...no...
TIM: They got bought by AOL.
ADRIANA: Oh...
TIM: and AOL ruined WinAmp.
ADRIANA: Oh, jeez.
TIM: Yeah, it was awful. I will never forgive them for that. They ruined WinAmp.
ADRIANA: Oh, jeez.
TIM: Uh, do you remember ICQ?
ADRIANA: Yeah, absolutely.
TIM: ICQ was great. It is still, to this day, my favorite messaging platform. You know what happened to ICQ?
ADRIANA: I don't, no.
TIM: They got bought by AOL
ADRIANA: Get out of town. I did not know that.
TIM: Yeah, AOL ruined ICQ. Right?
ADRIANA: Oh, man.
TIM: Do we see this trend, like, what's happening? A pattern. When we talk about this thing of, we're going to buy this thing and then stops. Do you remember HipChat?
ADRIANA: Yeah, I vaguely remember it. I never used it, but I do remember it. Yeah.
TIM: And it was kind of cool.
ADRIANA: I never use it, but I do remember it. Yeah.
TIM: It was kind of fun. And then it got bought. I think it was either Slack bought it from Atlassian and then shut it down.
ADRIANA: Interesting. Oh, shoot.
TIM: And so when we start seeing this kind of thing where we're like, oh, well, we don't actually want to build a better product, right? We want to eliminate people's ability to choose between products, right? So we don't want to actually have to compete because that's too expensive, right? So it's just cheaper to buy them out. And then not have to make something better, right?
ADRIANA: Yeah.
TIM: And so that kind of thing is like, I don't like that. Let the community decide if your product is better. Great. People will use it. They'll buy it, right? Or if there's more of a compelling reason for them to use it. If it's less expensive, if it...service is better if it's just more available, whatever it is, right? Let people choose that, right?
ADRIANA: Yeah, absolutely.
TIM: Don't kill the competition with a pen and lawyers. Kill the competition by building a better product.
ADRIANA: Yeah, I totally agree. I totally agree. Yeah. It makes me think of Oracle as well. I spent many years as a Java developer, and so in my Java days, like, the Java app server, my favorite one was, like, BEA WebLogic, and I think Oracle bought them in and was like,
TIM: But so many things that we enjoyed have been ruined by acquisition, right?
ADRIANA: Yeah, it's super sad.
TIM: So when we see this trend continuing through stuff that was used and or beloved by the open source community, it's just more things like, we can't trust corporate interests to have our best interests in mind, because they don't. What's good for the corporation is almost never good for the customer.
ADRIANA: Oh, definitely not. Definitely not. Yeah, I feel the same way. I think that's one of the things that frustrated me when I started working was realizing, like, the world is more nefarious than I would like it to be. I'm like, Why can't we all just be friends?
TIM: But I think what's worse than that is that there's also the narrative by some straight white dudes on Twitter who are like, oh, well, you're a highly paid capitalist person. You can't be against capitalism. I'm like, just because I detest the system doesn't mean that I'm not good at it, right? Matter of fact, because I'm good at it is why I detest it, right? I'm coming from a place where I know how it works and I know how to make it work for me, and it's terrible.
ADRIANA: Yeah
TIM: I shouldn't have to, right? That's not hypocrisy, that's understanding.
ADRIANA: True. Yeah, I totally agree with you.
TIM: But I'm not going to mention any names, who it is. They know who they are, and they're probably listening to this.
ADRIANA: Now, pivoting...I want to pivot back to a thing that you said earlier when we were talking, when we were doing the rapid fire questions, the Dev versus Ops. You said you had opinions, so I want to hear them.
TIM: Yeah. So here's the thing, right? There has been this long, probably a good ten years worth, if not longer... But I know for ten years at least, move to minimize the role of Ops in what we do for software and product delivery, right?
ADRIANA: Yeah.
TIM: There's DevOps. And they're wrong by thinking this, but a lot of folks think like, oh, it's when dev people do Ops or Ops things gets automated, right? That's not what DevOps is, right? Remember the NoOps push for a while?
ADRIANA: Oh, God.
TIM: Like, oh, we don't need Ops.
ADRIANA: It's like no code. Like, yeah, right.
TIM: Yeah. What they're saying is we're abstracting the work of operations away so that devs don't have to be concerned with it, so that they can just do on development. And a lot of developers think that the sun rises and sets by whatever they type out of their fingers and it doesn't, right? The realty is that developers are a skill, don't get me wrong. It's skilled and very difficult. Not very difficult because it's not like any of us are doing brain surgery, right? It is a skilled and it is a highly complex skill set, right? But it is only a piece in the cog, right?
And developers are not rock stars, right? They're not. I don't care. The notion of a 10x developer is bullshit, right? You can have all the developers in the world you want to, and you're just going to be developing...you're going to be running stuff on your laptop if it's not for operations, right? Everything happens because of operations, right? And we rely on each other. Like operations need developers to write software for them, they need developers to write drivers, they need developers to write firmware. Like all that kind of has stuff, like APIs, like that also has to work.
But when you need stuff to work and you want to make money, it's your operations and support teams that actually do that, right? Developers will get you sales, operations will get you renewals.
ADRIANA: Yeah, that's actually a really good point.
TIM: And what does any business want more than sales? They want renewals. Let's talk about get renewals from Ops, right? But I think, I think where we come where we come off the rails in a lot of this is like, what are our roles? We're developer relations roles, right? I work for a hardware manufacturer. We don't you know, I should be talking to operations, right? If if you do any kind of API for hardware, stuff like that, you should be talking to operations folks. Unless you're selling specific developer tools, then you should be talking to devs. If you're selling things that people consume in their operations, especially anything around infrastructure or networking, you should probably talk to operations too, right? But we focus on developers, especially when it comes to salaries and stuff like that, because we're thinking, oh, well, operations can be obfuscated away and do this and this and this and this, right?
But the operations knowledge gets more and more complex, like how many Ops folks when people talk about using Kubernetes as we abstract away more stuff or like platform engineers like that, they're just operations folks, right?
ADRIANA: Yeah, absolutely.
TIM: We're providing a platform for developers to use because we do not want them interacting with the hardware, you know?
ADRIANA: Yeah, yeah. Sorry. Go ahead.
TIM: And so, and as it so there's this...they change the name for operations over and over again, right?
ADRIANA: So true.
TIM: Because they don't want to just come out and say like, hey, these are Ops folks.
ADRIANA: Yeah. I completely agree with you. And it makes me think of something. And to your point, operations folks have been tasked with learning more and more and more stuff, right? Like, picking up managing Kubernetes clusters, and learning these IAC tools and like, you know...
TIM: Managing Docker repositories and then CI/CD tools and stuff like that. People who are called DevOps engineers, they're just Ops folks, but they're working on the internal tooling, right? That's all it is, right? But it's funny because really, ideally in the pie in the sky world, the very last concern that a dev is going to have is like, okay, I am now going to package this thing up. That's where it should end. And maybe not even that. I'm just going to commit it to main, right? I'm going to commit it to the production repo. That's where I want you to stop, right? Cool. We've got it the rest of the way, right?
Once it gets committed to production, to the production repo, everything else is operations at that point, right? And that's kind of how it should be. I don't want the developers to have to work and not that they can't. I just don't want them to have to I want you to just go back to developing, fixing bugs, developing features, right? Operations has the rest.
ADRIANA: Yeah. Now, do you think, though, that it's helpful to have that mutual empathy for what each of these roles entails? Right? Because I do feel like maybe there is this us versus them mentality with Devs versus Ops, and I've been on both sides of it, and I feel like especially when it comes to developers are done developing their feature, throw it over the wall, it's gone into production. That's it. And now there is a bug that arises, like, not my problem.
TIM: So I think that's the whole thing that DevOps is supposed to be solving, right?
ADRIANA: Yeah, supposed to be...
TIM: The throat of the wall, the silent isolation it's supposed to be solving, like they turn into all these other things, and it's not.
ADRIANA: Yeah, absolutely.
TIM: DevOps is a culture, right? A culture of collaboration and interoperation, right? Where Ops has these levels, concerns and the roles and things they got to do great. It should be informed by what devs do. Devs should be informed by what Ops do. Ops should be able to say like, hey, these are things we found has this problem, this problem, this problem, this problem. So you need to work that into your dev cycle to get these things fixed because these are not operations issues. These are like software bugs or whatever. Right? Cool. That's great. Dev should be able to say like, hey, it's supposed to do this and this and this and this. So when you're designing architecture reviews like that, you have to make sure this and this, it is going to rely heavy on this caching thing. So you have to make sure it's robust. Those are the things that Ops folks should be concerned about with that. Right?
I think what ends up happening, and this is just my observation as an Ops person, that Dev has very little knowledge or concern about what happens in Ops. Right. But Ops, by the nature of the role, has to be concerned about the code that's coming out that they have to deploy. Right? And I think to the extent where Devs do not concern themselves with Ops and they think that the whole world revolves around them, that poisons the culture.
ADRIANA: Yeah. Absolutely.
TIM: And then you end up developing kind of practices around that notion where Dev is the most important thing. Right, but the customers don't interact with the Devs.
ADRIANA: No, they don't.
TIM: Customers interact with Ops.
ADRIANA: Yep, yep.
TIM: And that goes back to what I said before about customer-driven development and having context for the things you do.
ADRIANA: Yeah, absolutely.
TIM: Right, but in the end, I think what's so interesting about that is that we have to have this kind of cultural coming to Jesus moment. But also that's an organizational thing because not all organizations are like that, but a lot of them have come that way and that's where the leadership comes in. Right, but we're not doing leadership, we're doing management. Those aren't the same thing.
ADRIANA: And that's where I think having those honest conversations that so many organizations lack becomes a problem as well. Right? You've got people not wanting to admit when there's a problem, people being basically creating their own kingdoms and wanting to protect their own kingdoms and not thinking outside the kingdom. You launch into those sociotechnical issues that plague so many organizations. I definitely see that a lot in big organizations, but it doesn't mean that the small organizations aren't immune to them either. I mean, that can easily happen.
TIM: I think that's kind of what you talk about. It's like you talk about how do we do these things? We've created so much tooling and so many products so that we don't actually have to talk one with another, right?
ADRIANA: Yes.
TIM: So that we try to automate, not even automate empathy. We're just kind of like, oh, we don't need emotions or empathy about this because it's not about the people. So it's like Slack. Why do we have Slack? Because we don't really want to talk to people, we want to be able to chat with them. Right? Why do we have GitHub issues where we interact with people, like over text? But a lot of times too, if you just...not that you can't do this in remote culture, but just like we're doing like, hey man, let's pop into a Zoom meeting for five minutes and we'll talk about this thing. Great. All done. Right.
ADRIANA: Yeah.
TIM: And yes, I understand the large distributed teams where asynchronous communication is very important, you have to be able to communicate that way, to collaborate. And that's fine. But you understand it's going to be slower, right.
ADRIANA: Absolutely.
TIM: But if you want to quickly, let's have a conversation. We can understand each other, have some and then I can understand your side better. Or what? Your...not even your side. I can understand what your concerns are better. Right? And have context for why you're saying the things that you're saying or why you have the concerns that you have. And now they can become my concerns, or I can address the concerns that you have a little bit better.
ADRIANA: Yeah.
TIM: Right, but we have so many tools so that we don't have to do that's.
ADRIANA: So true. And I think part of it, too, is people are afraid of confrontation. Like, it's easy to hide behind a chat window, right? But as soon as you're face-to-face with someone, it's it's easier to hate someone or what they're doing behind the chat window. And then the face-to-face is like, there's a person.
TIM: Well, I think it's weird because some people rely on other people. Like, that the stereotype of that one asshole engineer that always makes it hard for everybody else. It's a stereotype because it was very often true in a lot of orgs, right? They're relying on getting their way because people don't want to have arguments or confrontation or whatever. Right? And it doesn't have to be about that. It's like, hey, man, you actually don't have that much power. You can argue about all you want to, but once we go for this peer review...in that way, it's good.
Right, but at the same time, it's like, if you have to do that just to deal with this one person, how about we just get rid of that one person who doesn't know how to be empathetic and work on a team? Doesn't matter how good he codes, if we have to implement all these things just for this one person.
ADRIANA: Absolutely.
TIM: You should have organizational fixes, but also you can get rid of toxic people in your org.
ADRIANA: Yeah. And that's an interesting point because I think there's this mentality in a lot of teams where, like, oh, but this person is a superstar. We can't possibly get rid of them, but they're fucking with the team's mojo, and that can be worse than having this superstar who knows their shit and fixes things and blah, blah, blah. Because now you're affecting the morale of your other folks, and then that can create tension in-fighting whatever. Right?
TIM: Yeah. And we see this like...I'm going to draw a parallel to sports teams. You've seen sports teams that have one superstar player and the rest team is garbage. Right? Or even if they're not garbage, that one superstar player is a problem and it causes discord on the team. Right? They're a problem in the locker room...
ADRIANA: Absoluelty
TIM: ...they're a problem with the whole thing. They get so much attention. Negative attention. Right? That the rest of the team falls apart.
ADRIANA: Yeah.
TIM: And as soon as they get rid of that one person, they're great. Right? But you can have a superstar player that makes other people around them better. Right? You look at like, Michael Jordan, right?
ADRIANA: Absolutely.
TIM: One of the great examples. Was he a jerk? Yeah. Was he good? Yeah. But did he make other people around him better? Absolutely. Right. And like, that's what you want. You don't want to have somebody who's just, well, this person knows this one technology really great. You know what, I can deal without that. I don't have to have that. If you have to have that, that's a business failureship. That's a leadership failure. Failureship. Failureship.
ADRIANA: Yeah.
TIM: That's a leadership failure.
ADRIANA: I absolutely agree. I think it all boils down to just focusing on the human aspect of...we are humans working with other humans. And we should not forget that. Like, we do not work with robots. Not yet. Maybe someday. Sorry.
TIM: So we work on robots, right?
ADRIANA: We work on robots. Exactly. Perfect. Yeah.
TIM: But technology is inherently still about people. People consume it. People need it. They have needs that they want to address, right? We're basically using these things to solve problems, right? But again, technology for the sake of technology is just masturbation, right? We need to be able to have interoperations of team. We are software engineering teams. We are operations teams. Company is a team, not a family, right? We're a team. And so we have to interoperate.
And it's so funny because if you think I'm going to go back to a sports reference for those, you know, it's like everyone on the a lot of people will make fun of the kicker until that kicker needs to save the game, right? And then all of a sudden the kicker is the hero, right?
ADRIANA: Yeah.
TIM: There are no unimportant parts of a team, right?
ADRIANA: Yeah...
TIM: People like, "Who's the long snapper?" People know who the star quarterback is, but they don't know who the long snapper is. But the long snapper can lose a game for you. You know what I mean? That's an important thing to remember. The team exists with all the people in it. It's not all about one person. Everybody on that team is necessary and important
ADRIANA: Yeah.
TIM: whether or not they are rock stars. And then you can extend that beyond just a single team and talk about the interoperability of various teams in an organization like you're. We're about to have some fucking tea right here, my friend. Do you know how sick I am of mostly developers I'm going to go back to that again who are very self-righteous and very degrading to people who are quote unquote, non tech roles like HR, like sales, like customer success.
All these people like that. They are why you have a job because of them. I may not agree with having sales pressures, but I will never say we don't need salespeople, right? Because somebody's got to talk to these people because you can't you're not good at that.
ADRIANA: That is so true.
TIM: That's not your role, right?
ADRIANA: So true.
TIM: You need to be understand some of these pressures. You need to be able to interface with people of various roles and really go out there and put yourself on the line, right? You have to be able to make sure that we all get paid.
You have to make sure that we all have insurance and make sure that we get people in here hired. You have to make sure that your video conferencing stuff works, that you're laptop works.Like all these things are not we don't have anybody that we're not going to say not anybody. For the most part, people are working there because their role is necessary, right?
ADRIANA: Yep, absolutely. Things don't happen by magic and fairies.
TIM: When people say, oh, the Rockstar, you know what, I've had Rockstar office managers that they paid six figures and absolutely they were worth every penny because they made the stuff happen, right? Yeah, absolutely. I've had Rockstar recruiters everybody at a company. Their role should be important and should be necessary, right? Even if they're the long snapper or the punter.
ADRIANA: The yeah, totally. I love that so much. Well, we are coming up on time, but before we finish off and you've given us so many awesome hot takes, but do you have any final hot takes to impart or pieces of advice?
TIM: Honestly, the final hot take and piece of advice that I want to impart is to stop having sales-driven development, right? We talked about resume-driven development. We make things overly complex and complicated just because because so and so...and we shouldn't have that but we also shouldn't have development based around a sales quota or based around anything like that. Like, no, man, make the product. Make the product good.
ADRIANA: Yeah.
TIM: Make the product something that people want to use. Right. And then we'll get it sold. Right.
ADRIANA: Totally.
TIM: But don't go chasing waterfalls. Just stick to the rivers and the lakes that you're used to.
ADRIANA: I love it. I love it. Thank you, Tim, so much for geeking out with me today. And y'all, don't forget to subscribe.
TIM: My pleasure.
ADRIANA: And be sure to check out the show notes for additional resources and to connect with us and our guests on social media. Until next time...
TIM: Peace out and geek out.
ADRIANA: Geeking out is hosted and produced by me, Adriana Vilella. I also compose and perform the theme music on my trusty clarinet. Geeking out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the Socials by going to bento.me/geekingout.