Ep. #34, The DevOps Transformation with Gene Kim of IT Revolution

Grant: All right. Gene, thanks so much for joining.

Gene: Oh, it's so great to be here, Grant, and delighted to be on.

Grant: Great. So let's kind of jump right in. Can you tell us a little bit about your background?

Gene: Yeah. I have been studying high-performing technology organizations since 1999, and that was a journey that started back when I was the founder of a company called Tripwire in the information, security, and compliance space.

So back then our goal was to understand how these amazing organizations had the best project due date, performance, and development, the best operational stability and reliability and ops as well as the best posture of security compliance.

So the goal was to understand, how do those amazing organizations make their good to great transformation so that other organizations could replicate their amazing outcomes.

So I was at Tripwire for 13 years, and the biggest surprise is how this work has really pulled me into the middle of the DevOps movement, which I think is so urgent and important.

Name any software company that isn't being affected by the new practices and principles and patterns that allow us to do things that were just impossible 10, 20 years ago, the notion of doing tens, hundreds, or even hundreds of thousands of deployments per day--

Which is certainly better than doing one deployment or release per year, and there's no doubt in my mind that doing that not only gets us better value sooner, safer, and happier.

It allows us to win in the marketplace.

Grant: Cool. Okay. You mentioned you kind of started that at Tripwire, right, a company that you helped found.

Can you just dive a little bit in the backstory of Tripwire?

Gene: Yeah, for sure. So we created the company in 1997.

That was actually based on a program that I wrote when I was an undergraduate student at Purdue University.

I was working for a professor named Dr. Gene Spafford.

He was actually the whole reason why I went to Purdue in the first place. I was working in high school at Sun Microsystems as a part-time QA engineer, part-time CIS admin.

That was around that time 1988 is when the Morris worm hit.

So November 2nd, 1998, the Morris Worm took down 10% of all the servers on the internet.

I think the number is about 60,000 servers at the time. So I mean, 6,000 servers affected.

But was actually the first real kind of massive attack of the category we had seen.

So what really I was riveted by that I've read everything I could and the person who was doing the most amount of publishing on it was this guy, Dr. Gene Spafford, and that's actually why I went to Purdue in the first place.

I didn't know. It was really in the cornfields of Indiana. I think even if I had known, I would've still gone there.

But then that was kind of a rude shock. But it was such a rewarding time.

So that rapidly became one of the most widely used security tools for Unix.

So think back to the late '90s. That's the time of the dot-com boom is the rise of e-commerce before the dot-com crash.

So this is when things like PCI. The predecessors of PCI was called--

I think it was called CISP from Visa. MasterCard had one.

This is when you started having the first data security standards for what you had to do to secure cardholder data.

Grant: Interesting.

Gene: So that was really pointed to the need for some sort of commercial offering to be able to secure data at rest.

So that was the reason why I had created the company.

Grant: Okay. So where did you grow up? It sounds like not Indiana.

Gene: Right. I too grew up in Minnesota.

Then I in high school was in Colorado, and that's when I had this amazing opportunity to work half-time in high school working at a company that was then acquired by Sun Microsystems.

So that was just an amazing glimpse into what it was like to work on great engineers and get exposed to infrastructure and operating system administration and networking.

I think that those are certainly very formative experiences throughout my whole career.

Grant: Yeah. That's pretty awesome.

So you're doing that in high school, and then this bug, and you went to Purdue to spend time with this professor.

So you wrote the initial version of Tripwire while still in college with this professor, or what's the--?

Gene: Right. That was an independent study project.

I remember writing it and see right now that was all publicly available, open source.

That was really a well-defined construct.

So at Tripwire, then my first job was essentially hiring up the team to write the first commercialized offerings, building out that organization, headed up the marketing organization despite having a very unsophisticated layman's view of the whole practice.

But yeah. So you know how it is in the early days, where it was just an amazing adventure of being a part of every process in the company, and what a relief it was to hand that off to professional engineering managers who actually knew what they're doing.

Grant: So I guess that project that you created had gotten some adoption after you wrote it in college, or what was the impetus?

I mean, because there's a few years between you wrote this, and then you started the company, right?

Gene: Yeah. So the way we released software back then is you posted the source code on the use net newsgroups.

So on top that source of that Unix, I think is where we published it.

By 1997, it had become the most widely used unit security tool for defenders to administer the systems.

So that was definitely a benefit and advantage we had being able to leverage the fact that so much of the market already knew about your buyer, and it does--

I can't remember who said this, but obscurity is difficult to monetize.

So the officer says at the end when people kind of associate Tripwire with being a good responsible system administrator or a security administrator.

Right now, that was a phenomenal advantage in the early days of the company.

Grant: You'd probably had you mentioned at least an internship before companies you'd been at.

Did you have, I'm going to quote unquote, "a real job" before you founded Tripwire?

Gene: No. Before the Tripwire experience, my primary experiences were either full-time engineering, to some part marketing and sales support, but never at the scale of a startup that was solely focused on software selling to enterprises.

Grant: Well, yeah. Then this is like the height of the dot-com, sort of like rise. Right?

So I'm guessing there was probably a lot of venture capital or scale-up. What were those early days like?

Gene: Oh, yeah. So my co-founder was Wyatt Starnes, and he was superb at raising money, and I think we all agreed by 2004, we had raised way too much money.

So these numbers sounds so small compared to what's being done these days.

But back then, I mean, I think we all look back and say, "Holy cow, the fact that we raised $55 million was way too much."

It was one of those cycles where you raised money, you run out of money and in order to raise more money, you had to raise a sales forecast, and you repeat that a couple of times, and there's no hockey stick that you can grow into to justify the valuations that you're boasting.

One of the most amazing things in the company history was on 2004 where we had a new CEO come in, and this was Jim Johnson.

Yeah. He was such a remarkable leader. He was the site manager for all of Intel in Oregon.

It sounds like a very humble title, but essentially, he was the operational leader for basically all the non-P&L functions for the entire state of Oregon for, I think what, the 6,000 to 12,000 people.

So I mean, he was operating at very high levels of the company.

So for him to come in and really look around, since he had one goal for the company, and that was to make a buck.

Grant: So funny.

Gene: It was amazing that within, I think it was like six months after he came in, we made our first profit.

I mean, it wasn't much, right? I think it was like--

I can't remember if it was $10,000 or $50,000.

But it was the one milestone that stands out in my head is something that I was so proud to be a part of the fact that it really cross-functional focus and the operational discipline to get rid of all these bad habits we had acquired in the previous years and really show that we could be self-sustaining.

So yeah. So when you raise a lot of money, you get these Lucite plaques, right?

It got to the point where I didn't have enough room for these Lucite plaques, right, from all the investment bankers.

It's kind of a bad situation when you're the investment bankers, best friends. It's like that's not a situation you want to be in.

The one Lucite plight that I still am very proud of is we made a buck, right, that was given out to every one of the company employees.

Grant: Oh, funny. Your role at Tripwire, I mean, from sort of the founder, co-founder, CTO, were you managing large teams?

Were your primary focus on product and technology?

What were your focuses, I guess, in the beginning, and then it probably changed over time, but--

Gene: Yeah. At various points in that early in the organization, I was leading the engineering function.

So now, by the time we brought in a professional engineering leader that was by about 30, 35 people, and then for a while was helping run the marketing function.

Then I loved the idea of being a individual contributor.

So for the vast majority of my time at Tripwire, I really divided up my role into three parts.

One was do whatever it took to help the sales organization do whatever they need to do to win deals.

The second one was do whatever I could to help elevate the visibility of the company and myself.

Then third is work internally with engineering leadership and a product leadership to help create a long-term roadmap.

So that was definitely much easier earlier in the company up to Tulsa.

I think for me, the dividing line was about 180 people, where I think after 180 people, operating as a individual contributor just got a lot harder.

It felt like by the time you got the senior directors in, it's just the surface area of influence just became so much wider, and it just got a lot harder to do things that I wanted to do. My ability to influence the organization was a lot smaller.

So that's something I didn't really understand at the time.

People who I studied who I think have done it better kind of after the 150, 180 group was someone like Tim Keanini.

He's now a distinction engineer at Cisco.

When he was at the circle, he migrated from the CTO role to heading up professional services and customer success, which I thought was a really great idea, just because his contribution was certainly looked like an individual contributor.

But he really had the voice of the customer, right, that he knew what was happening.

He was having to deal with all the consequences of promises made to organizations to get the deal. Right?

He felt that too fresh on services, right, and it's customer success, right, and product management.

I mean, he was increasingly in a point where he owned the roadmap.

So I think there are a lot of ways that now almost 20 years later, I don't know to have done that differently.

Yeah. But it's another kind of an interesting reflection I've had lately is now 150, 180.

That is around Dunbar's number, where the scientific definition is, what is the number of people you can actually have regular interactions with, and its around 150, 200 people, and that's the round in organizations, and when you have hierarchical management structures, which typically do need to exist, that's where you have to introduce kind of the senior directors between the VPs and the directors.

Suddenly, if you want to influence things, right, you have to work with a lot more people.

So I think that's where the ability to influence widely definitely gets more difficult.

Grant: Yeah. Interesting. So when you left, how many employees were there at that point?

Gene: Around 350? Around 2010.

Grant: Yeah. I mean, that's a long run. It's a good amount of time to stay with one company.

I'm sure it was a lot of learning throughout that time and a lot of growth and interesting sort of problems.

I mean, really, you were-- Realistically, I was very kind of the foundation of sort of modern cybersecurity, right, one of the foundational companies.

Gene: Yeah. I have so much gratitude for my time there.

I mean, I think certainly learned a lot, and there are times that were more fun than others.

But how can you look back at 13 years?

I looked back at it with a sense of pride of achievement and gratitude for all the people I worked with, and it is what allowed me to actually work full time after I left in 2010 on the Phoenix project and worked so closely with the early DevOps movement.

That has been one of the most rewarding things I've ever worked on. So yeah.

My whole Tripwire experience, I have nothing but gratitude and admiration for the people I worked with.

I guess the one thing, I know you love frameworks and sort of people who've done thinking on this.

I think kind of what is remarkable to me is just how much the software game has changed. I think we have such better tools to think with these days. I mean, I think the way people think about customer acquisition and customer retention is light years beyond the tools and techniques that we used.

I'm not saying that we were the best in the game.

In fact, in some ways we were sort of country bumpkins, right, in terms of how some of our competitors were.

But I remember my friend, Luke Kanies at Puppet.

He was a founder and left, I think the last two years.

But he had invited me to a meeting where he had invited Kenny Van Zant.

So he was one of the early executives at SolarWinds, and now he's at Asana.

He was talking about how they did a specific part of the SolarWinds process. Right?

He was describing how they looked at the download counts and were continually measuring how many of them actually resulted in activation.

I remember just hearing that, and I was thunderstruck, right? Because one of the things that we were--

The challenge was we were going through our S-1 filing process to go through an IPO in 2009, 2010 was it looked like-- It didn't look like.

It was a fact, right, that our cost of sales and marketing was twice as high as organizations like SolarWinds. Right?

So in other words, I think our cost of sales and marketing at that time was around 60%. Right?

Which left say 20% for R&D, say 15% for G&A, right, and that leaves 5% for profit, which was better than it was. Right?

But there were organizations like SolarWinds that had cost of sales and marketing half of ours.

So I think yeah, at the strategic levels, you were always thinking, "All right, we got to do something about it."

But one of the things that happened in organizations is the phenomena of postponement is just never a good year. Right?

We're in a recession, not a good time. We're potential acquisition alpha on the table. Right?

We don't want to do anything too disruptive. Right? It's just never a good time.

So you kick the can down another year down the road.

So when hearing the story from Kenny Van Zant, I can't describe the expression on my face.

I mean, I think the feeling was, "Oh my gosh, I could have reached out to him in 2008 and said, 'Hey, I'm going to be in Austin. Could I take you out for a beer? I'd just love to brainstorm about, what does the inbound funnel look like?'"

Yeah. I think that was 2011 or 2012 when I heard this.

It was just this aha moment of how methodical people were being about the customer activation rates and customer acquisition rates and tying that into the inbound, how do you tie the marketing function to sales? Right?

I mean, it was just a revelation.

So this is amazing to me how much good thinking has been done in terms of really systematizing that and using the scientific method to essentially do experiments to get really, really good at creating good customers.

Grant: Yeah. It's interesting. Then you kind of mentioned it earlier too, which is just generally in the software ecosystem.

We've taken a lot of these best practices, and we've turn them from patterns into tools that we can use. Right?

So now there's probably a tool out there that helps you do these kinds of customer acquisition and funnel analysis, and there's obviously DevOps tools.

So it's interesting to think about how likely some of these things that we just all take for granted now were novel and one-off projects inside of companies.

Gene: Yeah. In fact, I mean, here's one that I wish--

So that was certainly one aha moment that I've had that I certainly wish I had learned much earlier.

It's just not that that would have had a material impact on the fortunes of the company.

The other one that really blew my mind was when I was hanging out with some friends at Rally Software.

This must've been 2013, 2014. So it was before their acquisition by CA, and I got invited to what they call the quarterly steering meeting.

I mean, it too was a revelation. In the same way, I was thunderstruck in awe of what Kenny Van Zant was saying.

This was an opportunity to attend this quarterly ritual that Rally has, had at the time. It was amazing.

The CEO of the company went out and gave a state of the company.

All of the leaders, middle managers, team leads were there.

It was the state of the company, kind of a presentation on strengths, weaknesses, opportunities, threats.

Each functional part of the organization kind of gave a report out.

Then they really engaged the leadership of the team, talking about like choose options that we see.

Here's the advice you would give it to the top leadership. Here's cautions.

I mean, it was just this incredible vibrant problem-solving that took part over three quarters of a day. Right?

Then leadership came back and essentially went more than just, "I heard you." Right?

Here's how we're going to integrate it into the plan going forward.

I think so many of us, we had these kind of quarterly business review meetings that are just--

I have friends who have been through it that it's like a big waste of time. Right?

All the decisions have been made. Right? In some way, it's kind of a big charade.

It was in such stark contrast to what I saw that Rally did.

They actually invited their customers to it. I mean, it was just brilliant, and it was just the level of problem-solving and engagement throughout the leaders among the entire company. It was just dazzling.

I learned later that so much of that actually came from work with Dean Leffingwell, who created the Scaled Agile--

Sorry, Safe, which has been prioritized by Scaled Agile.

So some people would like to poo-poo it.

But I mean, there is no doubt that those forms, that philosophy, that level of engagement throughout the company, I mean, that's incredible. Right?

So you might lose some of it when you read the safe book. But to see it in action is something that is just incredible to see.

Again, one of those things that I think if any organization who adopts that and has the ability and bravery to do that in front of the customers, right, I mean, that will create better decisions and again, could materially impact the fortunes of the company.

Grant: Yeah. That's interesting. There's so many of those companies that are doing different things now in terms of how they run.

As we all go remote, we're learning so much about how WordPress and GitLab and these folks have been doing it for a while.

So we're fortunate that there's enough companies out there doing things differently and then sharing what they're up to that I think it allows us to all get better.

I think we're also lucky that there's just a sort of general continuous desire to improve. Right?

You saw these things, and you were like, "I want this now." You go to implement part of it, right?

Gene: Yeah, exactly. I want this too.

But there was also, as I was like describing, what did I feel like--

It was sort of the exhilaration of seeing something truly dazzling.

Then part of it was anguish, the feeling of like, "Oh my gosh, I'm learning this too late." Right?

This sense of almost remorse or kicking yourself that you didn't learn this earlier.

So it's a kind of a complicated set of emotions when you see something--

Whenever you see someone who's the best in the game doing what they do, right, I think there's often that feeling of admiration.

But when it's something that you did as well, right, that's actually a vocation that you chose to as a vacation.

Part of it's like, "Oh man, I'm so bad compared to these people."

Grant: That's so funny. I totally agree, and I get it.

You're like, "How did I not know this? I could do this too. But how have I missed this?"

So obvious everybody else. I think that's a common feeling particularly for founders, because it's like we're out there, we're doing our thing, and then everything feels like so urgent, right?

As soon as you learn about it, you're like, "I would implement it right away. This could be changing my company."

You've sort of already procrastinated on the idea by not having had the idea four years ago, right?

Oh, we shouldn't be doing this from day one.

Gene: I do think kind of my main lesson I learned on Tripwire is that you have to hang out with the best in the game. Right?

I mean, I think there's that famous quote. You are the average of the top-five people you hang out with. Right? It's spirituality and health and fitness, and so much of it is actually formed by the people you associate with. So I think the more you hang out with really great people, right, the more you actually just by almost osmosis, you pick up really great ideas, right, and hopefully, you're reciprocating as well.

Grant: You think that's just in terms of networking or hiring? How do you think about it?

Gene: All of the above. Right.

I mean, so I think if I were a founder, and I think this is something that Luke Kanies did really well.

In fact, I was dazzled by just how he set the bar so high in terms of his board of directors.

I think in anything that I do these days, I try to find who are really good at it.

I think the real trick is to find people where you have these relationships that are mutually exothermic, right?

There's a famous Tim Ferriss saying, right? You always give before you get.

So I think kind of the gift of the really good networkers are the ones who are always helping other people, and they've just integrated so much into how they show up and how they interact with people.

So when you're looking for the best in the game, right, you're actually doing a lot of planning and does a lot of intentionality so that you show up as someone who can help them.

Right? Often, that will elicit the reaction like, "Oh, what can I do for you?" Right?

The fact that you're even having that conversation, right, there's no better thing to hear than that.

Grant: Yeah. No, I love that.

I have a similar concept that I always called startup karma, which was like, you have to do a bunch of great stuff for other people and then eventually just because you're doing that stuff, people help you out as well.

It's just like how the ecosystem works.

Gene: Right. Absolutely. It's my personal observation, and it sounds COVID, right?

It's the people who learn the most quickly are the ones who are fairing better, and the ones who are learning the most quickly are the ones who have already established the best networks.

So I'm definitely a believer in that.

I mean, for the last 10 years, I mean, I think that mode of operating, that mode of thinking, and that mode of doing just pays off in spades.

Grant: Yeah. Cool. So let's think about maybe kind of back to building products, right, and building things and Tripwire.

Were there any enterprise features that you delivered that you just thought were so valuable, and then they enabled customer adoption or something?

Gene: For sure. I'll start by telling you the story of what led up to it.

It's actually one of the worst professional moments of my entire career.

Grant: Oh, perfect. That's what we want.

Gene: I think it was 2006. It was for the first time in my career, I'm actually watching one of our customers use our product, and I'm there with Tom Good, one of our senior engineers.

It was like the worst morning of my life. I mean, it was terrible.

I was watching this administrator struggle with our product, and one routine operation that we expected people to do once a week took 62 clicks. Right?

The whole time, he was apologizing saying, "Oh, I know there's a better way to do this."

There wasn't. I mean, I wish I could have said, "Nope, there's no better way to do this because we are uncaring people who care nothing about people like you."

This kind of triggered this set of kind of interviews, where we're asking our best customers like, "Could we just watch you do routine operations with it."

Someone was telling us about how to set up our product for 1,000-plus servers.

It took them like 1,300 steps, because they had to start over three times.

When that happens, right, I literally felt like I was going to throw up.

You feel like such a bad person, that you're inflicting the suffering on people. Right?

This is just one person, right? If you have thousands of customers, right, you're really inflicting suffering on people.

It was kind of over the next couple of weeks. I started to understand why the role of the Tripwire administrator was always given to the most junior person.

Because no one wanted to do it. Let me just preface this by saying, right, it's not like that anymore because we ended up creating a team that really started the US practice inside of Tripwire.

So this is like in 2008, it was three of us, a product manager, Tom and I, we went to Cooper University.

We got trained, just at least in the fundamentals of UX, how to design products that don't hurt people.

Then that became a three-year, I don't want to use the word crusade.

It was to try to figure out how to make our product more usable, and it was one of the hardest things I've ever done, because you're always in competition with features that the Salesforce wanted or that customers wanted, and we felt like this was even more important than that, right, is that you needed to have something that was less painful. It was always in competition with major initiatives or features that we needed to save a deal.

Yet despite all those challenges, I think we were able to move the needle in terms of addressing some of these usability issues in the product and changing the way that we develop software.

So that was a really-- In some ways, it isn't a feature like you're describing.

It really is more of a philosophy of, how do we fill in this hole that we had created for ourselves and our customers and reshape how we did product management and engineering so that we wouldn't create these jagged edges that customers would get hurt on every week.

Grant: Yeah. Yeah. There is something there about usability, right?

Just usability as a feature. It's an interesting insight, right, where we often lose sight.

Oh, I always say I have to take beginner's mind and kind of go back to the beginning and be like, "Imagine, I don't know anything about this product."

I come to it, or imagine I'm doing this work every day.

So really taking that mind, watching users use it, and then just sort of being blown away by how challenging it is.

But then you fixed it is the most valuable part of it. Right?

You got in there, and you delivered a better experience, I assume. Right?

Gene: Yeah. Oh, for sure. Right. I think they have that meme, right?

It's like you have Google, right? It's one field on a blank screen, and then you have your average enterprise app. Right?

It looks like every widget crammed into a one screen, that was what it used to look like.

So for us to gradually migrate to something that had usability and UX, and we adopted things like personas and context scenarios and so forth.

I mean, I think it brought a level of sophistication that I think it was much more widespread these days, but that was a real eye-opener for our team at the time.

I think what I find so interesting is I'm also grateful for that experience because as you talked about customer acquisition and retention, I mean, so much of it is about usability.

It's about, can you discover it? Is it in line with goals that they actually value?

It can be as simple as typography or copy changes, right?

So I think that is as important as the specific technology that you're building, right, is do you understand the user goals well enough, right, to really build something that they want to use.

So yeah. I think in these days of consumer software where things like Facebook, Google, and they have definitely mastered this.

But 15 years ago, that was absolutely something that we were struggling to not even get mastery of. It was just have some skills in it.

Grant: Sure. Yeah. Now you kind of have the consumerization, right, of enterprise, and it's made a lot of software much more usable in sort of modern enterprise software.

Gene: Yeah, for sure. I think the other thing that I gravitate towards, just developer productivity.

I think this is something that we did not as well in the early days of Tripwire. In fact, more war stories from the past may.

I mean, I remember, I think it wasn't around 2004.

But we had a cruise control server that ran all our builds and automated tests. One day it just broke.

So for I think a year, I had a bunch of engineers saying we need to get this fixed, right?

We'd have to open up a rec to hire an engineer just to get cruise control working again.

I think I was definitely part of the faction that said no, and I just didn't see it as being very valuable because we need to hire developers to work on features.

What I didn't understand until probably 2010, 2011, I'm hanging out with Jez Humble who wrote the Continuous Delivery book.

He was a coauthor on The DevOps Handbook. He was a collaborator with Dr. Nicole Forsgren on The State of DevOps research.

He was telling me about how important, continuous buildings, continuous tests are.

I'm just very laughing, taking notes, because it was so hilarious what he was describing.

Then I stopped laughing, and I realized, "Wait a minute, this is not funny at all."

The problems he's talking about is what happened to us in 2004. I totally missed it.

I think what's so interesting to me these days is that I think in most organizations, you put your best developers on features, and then you put your next best developers on backend APIs, and then you put your least talented developers on to build systems and dev productivity tools.

That's where you put your summer interns. That's amazing to me is if you look at Facebook, Amazon, Netflix, Google, it's the other way around.

They put their most senior, most experienced engineers on dev productivity tools.

In fact, this is often where you'll find the people with PhDs that have backgrounds in static code analysis and so forth.

Then the next tier is the backend APIs, and then you put the most junior people on features.

So I think it's the hidden killer of so many software organizations and whether it's an enterprise or in software companies is that you get killed by a thousand cuts, and you get in a situation where technical debt solely creeps into the system, and suddenly, you hire an engineer, and they can't do builds in the first two weeks.

They can't run test reliably. They can't deploy themselves.

We know that these are things that have to be integrated into everyone's stated work.

Because they don't have those productivity tools or infrastructure that developers use because they've been neglected, right, no one can.

In fact, I mean, that's what the unicorn project is all about.

It's the Phoenix project we told from a senior developers perspective, and when she gets exiled into the Phoenix project, this amazing engineer at the height of her entire profession can't do builds, can't write tests, can't run tests, can't deploy, right?

She's entirely stuck, unable to do anything by herself. It means that you can't onboard developers.

It means developers are not being productive.

So I think that is something that happens in way too many software companies and enterprise organizations even more so.

Grant: Yeah, it's interesting.

I do think that you've had a hand in this, but I think that's changing a bit in terms of, there's definitely more interest in DevOps than there was 15 years ago.

I think people see the value of tool building and of creating these processes.

We look at things like the container ecosystem in Kubernetes.

There's definitely a pretty strong, super smart ecosystem of folks that are focused on, how do we write tools to make it easier to build reliable software?

Gene: Oh, for sure. I think we're just at the tip of the iceberg in terms of where we should be.

If you look at Google, they have 1,500 developers focused on dev productivity.

So that's a billion dollars a year of annual spend just on making internal developers more productive.

Grant: Wow. That's crazy.

Gene: Yeah, it's incredible. It's about 3% to 5% of the total engineering workforce.

Microsoft is probably twice as high, 3,000 to 5,000 developers working on dev productivity.

So I would say rule of thumb, in my opinion, is not based on research, but kind of just based on my observation is that somewhere between 3% to 5% of engineers should be working on making other developers more productive so that they can spend their best energy solving the business problem.

I think in the world of Kubernetes, right, I think the worst thing that we can do to developers is make them learn Kubernetes, right?

I mean, I can personally attest to how difficult is the right Kubernetes deployment files and having to learn the vast surface area of Kubernetes.

I mean, it's an engineering miracle. It is amazing.

But that is so distant from the problems I want to be working on.

So I've gotten very fussy in terms of just certain searches.

I just never want to do in Google or Stack Overflow because it says to me I'm sort of spending my time in the wrong place.

So that would be my unsolicited advice to any engineering organization is like, are we forcing our developers to work on things and struggle with things that are distanced from the business problem?

Like logging, infrastructure, Kubernetes so far. Right?

So that should be provided by some sort of platform team. Yeah.

It should be abstracted away so that they can work on things that customers actually care about.

Grant: Yeah. I mean, the idea of a platform team I think has become fairly popular, particularly in larger organizations, right, providing a platform, providing all those sort of like infrastructure that you need in order to allow people to write software.

Gene: No, for sure.

Grant: One more question about your time at Tripwire before we dive into sort of some of your in the Phoenix project, things you've been doing.

What about sort of-- We talked about the most valuable feature, which was usability.

What about one of the hardest features to deliver? What was really tough that you did at Tripwire?

Gene: Yeah. I would ask you the same way. It was usability, right?

Because it wasn't to oversimplify it, the features get chosen is because as a market opportunity, deals that were associated with it or a category that we could enter if we had it.

So those are easier to attach a dollar value to, and things like usability essentially, we're kind of fixing the sins from the past, and it wasn't as easy to quantify, and I think kind of these days with the vocabulary of customer success and retention customer satisfaction, I mean, I think those more contemporary measures would help kind of elevate the need for.

But back then, right, it's so difficult to argue for it.

So I would put those usability village features as also the toughest to deliver, even though it doesn't look like a classic feature.

Grant: Cool. Great. Then let's talk about sort of I'll call it your second career. Right?

So how did you get into writing and speaking?

Gene: I think looking back or maybe even from the current standpoint, I currently self-identify as a researcher and an author.

I mean, that's the work I love to do most. Actually, let me put the third thing, and a coder.

So on a good month, I spend 50% of the time writing, 50% of the time hanging out with the best in the game, and 20% coding, working on problems that I want to solve.

I think that actually goes back probably at least 15 years.

I wrote my first book in 2004 called The Visible Ops Handbook, and the subtitle was How To Create World-Class Organizations Using ITIL.

So some people might laugh at that. But ITIL was better than what we had.

It was a great way to explain the critical processes that had to happen in operations far better than anything else that existed at the time. But I loved the kind of the mental focus of writing and codifying and categorizing and the notion of methodology creation.

My first work in sort of benchmarking organizations was actually during that time.

So I learned so many things that I then brought into the work around The State of DevOps report that I mentioned that with Dr. Nicole Forsgren and Jez Humble, where we've benchmarked 30,000, I think now 36,000 organizations over six years.

Some of those methods were something I had actually done in the late 2000s. So I'd love that.

I think the reason why I got support from so many people to do that when I was a Tripwire was that it really fell into that category of helping elevate the visibility of the company.

It was helping create awareness of what we thought was a market for the product.

In that case, it was really around-- It was a thesis that so much of security could be solved by better operational processes, like configuration management, configuration control, and so forth.

So I think what I benefited from, and I certainly, what I'm so grateful for now is I think those types of roles for any company executive, where they get to really hone their expertise and talk about the expertise more widely is something that's so valuable because it does elevate the visibility of not just that person but other companies as well.

I think there are so many great examples of this, where the CEO of the company and the CTO is the company, they're recognized as an expert.

So when they're invited to talk is really the company benefits because people associate the person with the company.

So it's fantastic because it not only helps the company, but it certainly helps that person, right?

Because it will help that person in every other endeavor they have for the rest of their lives.

So I think it's one of those activities that have such a high payoff, both for the individual as for the organization.

Grant: Yeah, I totally agree. It helps kind of create, I mean, they call it thought leadership, whatever else.

But generally, you're out there. You're helping kind of establish best practices and principles and patterns and then getting other people to sort of follow along.

Interesting that you sort of self-identify, right, as this sort of researcher and author.

That's how you define yourself, and plus a programmer.

But I'm guessing it felt like the thing that you wanted to do was kind of felt natural, right?

Gene: Yeah, absolutely. In fact, I'm just kind of thinking of other people who have done this so well.

I'm thinking about Adam Jacob from Chef, Edith Harbaugh from LaunchDarkly, the gentleman from Trello, Michael Pryor, DHH from Basecamp.

Right? I mean, these are all people that we identify as experts at their craft.

Grant: Sure.

Gene: So what is a value that they create just by being good at what they do and sharing their learning.

So I think those are people that I think have done a tremendous job.

What they've done is create such value for the software community as well as for their organizations.

Grant: Yeah. We have to get out and talk about these things, or else everyone has to solve it themselves.

So if we kind of get out there, and we share it, then we can all build and kind of stand on each other's shoulders to get there faster.

So okay. I mean, you've written a handful of books, right?

So this first one, when you were at Tripwire and then is when you left Tripwire?

Is that when you introduced the sort of Phoenix project or what was--

Gene: Yeah. Right. So that was in 2013.

So after I left Tripwire, I worked essentially full-time on that book for about three years.

So it came out in 2013, and I had two fellow co-authors.

Then two years after that came The DevOps Handbook with Jez Humble and John Willis and Patrick Debois.

Then I got to work on the Accelerate book with Dr. Forsgren, then Jez Humble again, and then a unicorn project came out November of last year.

So it's definitely the work I love, the long form writing style.

It's kind of a frustrating journey when it takes on average for me about three years to work on a book.

But there's something about it that I love just because I think for even these days, the best way to convey complicated ideas is through the long-form writing.

It's not something you can do through a blog post or in a talk.

Grant: Sure.

Gene: It does take, in some cases, writes 80,000 to 120,000 words to try to make an argument to make a case, kind of proactively handle all the objections, right?

There's something about that that I really love. Malcolm Gladwell, he wrote a lot of great books. What's the book about 10,000 hours and-

Grant: Outliers or something?

Gene: Outliers. Right. Then the book he wrote before that, which is a even better book.

Grant: Tipping Point.

Gene: The Tipping Point. Yes. Thank you. Right.

I had an interview of him, and he said he hates writing books.

He actually loves writing for the New Yorker, right, where it's an article you can write and ship within a month, right.

So I can definitely understand where he's coming from, but I definitely liked the kind of the longer form writing style, even though it does take a lot longer and is more of a Rocky process.

Grant: Yeah. With these books, I mean, you really helped kind of establish DevOps as a thing, right?

I mean, before some of the-- So obviously some of the companies like Puppet and Chef were helping sort of build a career around it.

But I think a lot of your work helped crystallize the best practices and make it--

It kind of gave people an introduction without having to go and play with technology.

They can kind of read and understand a bit about it. How do you sort of thinking about DevOps and its evolution?

Gene: Yeah. I think what the Phoenix project did, I'm so delighted, by the way, the DevOps movement has adopted the Phoenix project as a way to signal, this is a problem that we're trying to solve.

I think what it did really well was really portray how bad life was for everybody, not just for infrastructure and operations, but for security and for development and the businesses that we served.

What it allowed people to do is when people read it, in general, people's reaction is, "Holy cow, that's us."

Really, it was designed that way, and I think the reason why I was successful in doing that was that it was modeled after one of my favorite books, which is The Goal by Dr. Eliyahu Goldratt.

So this is a famous book that was written in 1984.

It was a novel about a manufacturing plant manager who had to fix this cost and due date issues in 90 days, although, as I say, would shut the plant down.

I remember reading this in the late '90s.

I've never worked in manufacturing. I've certainly never run a manufacturing plant.

But after reading this book, right, it was astounding.

I mean, it was an amazing story, and you couldn't help but feel the plight of these people who were struggling to keep the plant open and reading the book.

There was just no doubt that the lessons in these books were relevant to technology as well.

So we studied that book for a decade to try to elicit the same reactions, where instead of manufacturing people, it'd be technology people saying, "Oh my gosh, this is happening to us right now."

So I think that's what--

I'd like to think that it helped accelerate the adoption of DevOps and certainly the awareness of DevOps, and I think one of the things that I'm just really delighted by is that non-technology people can read it and say, "Oh, this is not a technology problem. This is a business problem that impacts me and really in the ideal, right, I should be a part of the solution to help them make a better way." So-

Grant: Yeah, that's interesting. I love that it was inspired by this other book.

It's like the reverse engineer or something that you thought was really good and apply it to a new category, right, I mean, that's how EnterpriseReady started.

I was like, "Oh, I think user onboarding is really great."

I think that all these different sites that I liked were good, and I was like, "I should do something similar for enterprise software."

When you take what's out there and you apply it to different categories, I love that.

Gene: No, for sure. I love that saying.

There are no new solutions underneath the sun, just old solutions applied to new domains.

I think in that journey, one of my coauthors, George Spafford, and I, we actually took three graduate courses in constraints management, just getting trained up so that we were, I wouldn't say expert, but we were certainly more than conversant in terms of how that book was constructed and the underpinning theories in the book.

Grant: Oh, interesting. I think about it this way too.

Obviously, there's a movement more recently called DevSecOps. Right?

This whole idea of like shift left.

But really, I mean, you came at DevOps from a security angle, right?

That's kind of one of the main reasons that you thought it was important.

When you sort of think about DevOps and security in this intersection, do you think DevSecOps is very different?

Do you think it's kind of the same thing? How do you view the evolution around that?

Gene: Yeah. So in the early days of The DevOps Handbook, I actually proposed to one of my coauthors, John Willis, "Hey, we should call it The DevSecOps Handbook." He just puked at it.

He was like, "We don't need to rename it." There's that joke, right?

It's like biz, dev, QA, sec, ops, regulations, et cetera.

He was adamant that it really should be The DevOps Handbook. I thought he made a very persuasive case.

We weren't trying to change DevOps. We were just trying to explain it.

I think the reason that I found that so compelling was that it was supposed to be a very broad umbrella for everybody to participate, whether it's a product manager, product owners, developers, QA, operations, security, et cetera, and all of those were kind of addressed in the book.

But what was funny is that John Willis is working on a book called--

I think it might be called The DevSecOps Handbook, just because now he's super interested in security and actually wants to go in even deeper in terms of what the specific practices that you can bring to bear.

You have to get the amazing outcomes as you shift security continually to the left. So I think security is one of these professions that is being radically changed by DevOps, that it used to be the case that, say 15 years ago, that if it wasn't in the GRC tool, like Archer or whatever you kind of maintain your control, catalog and risk frameworks, it didn't exist.

These days, if it doesn't exist in Jira or your work management tool for developers, it doesn't exist.

I mean, everything is really centering around developers, and it just changes everything. Right?

How we do static analysis, how we do dynamic analysis, everything about that and the cadence of when you do security activities is really changing.

So just it's a long, and it's a short is DevOps is changing everybody's jobs in the technology value stream, and security is probably the biggest amongst it.

I actually agree with John Willis six years ago, right? We'll just call it DevOps.

It is really a signal of everything except for the bad ways of doing things, right?

We'll just put all the bad ways of doing things and bad habits.

We'll call it non-DevOps, and I'll call the good ways, better ways DevOps.

That's kind of the way I think about it in my head.

Grant: Yeah. It's interesting.

I mean, I think it was GitLab publishers, they're like BizOps sort of practices, and there's definitely these different guides or strategies around how to operationalize different aspects of technology companies. Right?

Gene: For sure.

Grant: Then to your point, so I've always thought about this idea of security will intersect so many different categories, right?

If it's like you think about AI, there'll be some kind of AI sack, and there'll be some kind of intersection between security and whatever the next kind of crypto, and everything will always have a security aspect to it.

But to your point, I guess everything will likely always have a dev intersection as well. Right?

There's no categories that are not going to be impacted by how developers interact with the technology or with the problem because software really is eating the world. Yeah. That's interesting.

Gene: Yeah. Without a doubt. This is a really tough job.

But I think one of the things that's definitely clear is security has to be part of everyone's daily work. If it's not showing up in the tools and productivity systems that developers use every day, something is wrong.

So it was back to the sort of the, what are the tools and infrastructure that developers use in daily work.

Security has to be showing up there. If not, the outcomes aren't going to be so great.

Grant: Yeah. Particularly, I mean, you see we're talking on a day when every major technology exec is testifying in front of Congress, and it's about data privacy and data security and all these things.

It's like it's so core to our personal lives and our work lives that we all have to be thoughtful about it. I mean, that's changing.

The level of security that people understand, I think has changed in the last 20 years. Right?

Gene: Oh, and there's so much I don't know.

I mean, one of the big questions I'd left unanswered in the unicorn project is like, how do we treat data and security?

So I think one of the problems I'm been very riveted around is--

and one could argue is even bigger than DevOps is around data.

So what the DevOps movement rightly pointed out was it was so hard to get code to where it needed to go, which was in production so that customers are getting value.

So that's a big problem. But there's also this orthogonal problem around datas, which is how do you get data to where it needs to go, which is in the hands of people who manipulate and use data in their daily work to make better decisions.

That can often take months or quarters to get, because data is often stuck in systems of records or data warehouses, and now if you change one schema, you potentially break every scheme in the enterprise.

So this is a very dangerous activity.

So somewhere between 30% and 50% of employees use or manipulate data in their daily work. So it is a huge problem.

So the unicorn project really is-- A big part of the book is about exploring kind of, what does that look like when you're really making the best use of what you know about customers and markets and so forth, right?

Data is new oil, like the thing goes.

But the one question that is left completely unaddressed, and maybe when I have more time, I actually want to collaborate with some security experts and say, "All right, what does it look like when you have data about customers and potentially every developer can discover it and access it and use it to do their work better and make better decisions on behalf of the customer?"

How do you secure that, right? How do you give them enough information that we can actually improve the quality of decisions to be made and yet not compromise data privacy for consumers or whoever, right, on the transactions, et cetera?

So I think I would personally love to get more clarity in terms of, what are the ways to think about the problem that can make this manageable, and so we can actually, with a straight face say that we are doing what's best for the consumer.

Grant: Yeah. It's a really complicated problem.

To your point, I think that question has become much more relevant in the last four or five years than it was prior.

I always sort of say, I think that there's this relationship that enterprises have with the data that they touch and collect.

I think it's really changed in the last few years, where I think enterprises or organizations used to think they owned every bit of data that they would touch or collect.

Now, I think that the relationship has shifted from one of ownership to sort of stewardship or custodian of--

Gene: Custodianship. Yep, absolutely.

Grant: Yeah. I think that really, to your point, it has a ton of downstream effects in terms of, well, now they're responsible for being the custodian of this data, and how do they make sure that it's treated properly and that if someone's not misusing it, and any use is done in a way that is not only secure, but potentially even socially responsible and socially aware. Right?

Gene: Yeah.

Grant: Super interesting.

Gene: Right. At the time of this recording, there are a whole bunch of people testifying before Congress, right, that they're probably making certain assertions that they're being good stewards of data.

Grant: Yeah. Exactly.

There's a lot of data that enterprise software companies ended up having, right, and that the--

Or if it's on-prem, and it's a lot of data that's running through these applications that are produced by us.

So we need to think about, how do we handle data, then how do our applications that we deliver handle and simplify true data custodianship. Yes.

Gene: Yes. I look forward to more clarity on this, problem personally speaking.

Grant: Yeah. Yeah. I'm excited to see.

I like that you're going to dive into it, because I think you do a good job of sort of getting deep into a subject matter and trying to explore the different options and coming up with some best practices that we can all look for.

So that would be very valuable to the ecosystem.

Gene: Right on.

Grant: So where do you see yourself going next? Is it more writing, more researching?

Are you ever going to start another company again? What do you plan on?

Gene: Yeah. I'll tell you what I'm working on these days.

I mean, so my area of passion for the last seven years, six years has been studying how DevOps is being incorporated and adopted not by the fangs of Facebook, Amazon, Netflix, Googles, not by the unicorns, but by the horses, large complex organizations that have been around for decades or even centuries.

One of my favorite books I've read is by Dr. Carlota Perez, who explains that when you have these breakthroughs and technology, that's pioneered by, say the tech giants, you have this boom phase.

You have a bust. You have a period of incredible regulation as society comes to grips of like what to do with this new technology.

Then typically what happens is like a five-decade golden age that's fueled not by financial capital.

There's a lot VCs, not investors, but by production capital.

So in other words, organizations that are the largest brands across every industry, vertical, taking the lessons learned from the tech giants and using it to compete and survive in the marketplace.

So this technical revolution is one of five that has happened over the last 300 years.

So it's the age of steam, the age of rail, the age of heavy machinery, the age of oil and gas, the age of mass production.

So this is the fifth revolution. So it's been so exciting to run this conference called the DevOps Enterprise Summit since 2014.

Over the years, we've had 200, 300 organizations present their experience reports of, what was the business problem they started to solve, what's industry to compete in, where did they start, and why, what did they do, what were the outcomes?

So let's see.

I was to go through the financial verticals.

It's Bank of America, JP Morgan, Barclays, which was founded in the year 1634, which predates the invention of paper cash, BBVA, Jaguar, Land Rover, BMW, Chrysler Fiat, Nordstrom, Target, Nationwide Insurance, so military agencies, government regulators.

So it has been so rewarding to see these leaders create these rebellions, trying to overthrow an ancient, powerful order who is often quite happy to keep doing things the same way they've been doing for the last 30, 40 years, and to see them succeed, and often they're being promoted.

Essentially, to me, that's an indication that the organization recognizes that they have helped their organizations win, that they have the best long-term interest of the organization at heart, and they want them to do more of it.

So that has been the most rewarding thing that I've been able to do is really study this community.

So we've been doing two conferences a year, and holy cow, COVID definitely changed that.

So we ran our first virtual conference a month ago, and holy cow, I told everyone around me, never in my entire career have I done anything with such time urgency and not knowing anything of value about technical delivery models, cost models, revenue models, value proposition models.

But I'm so delighted that it was I think the best program we have together.

But I think the reason behind it was that the mission goes on, and the mission really is to help these technology leaders succeed and create this community that is helping each other succeed.

Why is that important? Because I have this conviction based on the work of Dr. Carlota Perez, who actually presented at a conference last month, that as much wealth as the tech giants have created, it will be eclipsed by the wealth that will be created over the next 50 years.

So the previous 20 years has been a period of incredible wealth generation, but also wealth inequality, right?

The gap between rich and poor keeps growing.

That's what's happened in every one of these technical revolutions, where there is a lot of creative destruction.

What eventually happens, in fact, she even posits it's so much of the social unrest and the rise of populism is caused by the people who have been hurt by all this creative destruction, offshoring, outsourcing, dislocation, and so forth, and all these things eventually get addressed in the golden ages that come next, when essentially, every industry starts adopting these new technologies.

It basically incorporates technology into the core strategy and operations as the companies, and that is what actually brings back more equality into society.

That's where you see the advances is a societal gains, and it creates the tide that lifts all boats and increases the standard of living for everybody.

So I just think this is such an important thing that's so much larger than DevOps, is really about, how do we really exploit this technology across all of the economy and society, just like we did for the age of mass production.

100 years ago, there were a hundred car startups in Detroit.

As much as, well, that was created then, right, that was actually dwarfed by post-World War II, where it was a combination of the automobile, combined with the interstate highway systems, combined with the revolution supply chains, right?

That is what generated the greatest economic expansion the world has seen.

So I think that's what hopefully we can look forward to in the next decades to come.

Grant: Yeah. That's actually super interesting. One, I love this thesis.

It's actually not one that I've heard anyone else really talk about.

So one, it's rooted in sort of these historical analysis of these transformations, and then two, the positive outlook felt like this is going to have a massive positive impact over the next 50 years or some 40, call it a couple of decades.

If we think that the rate of change, at least it's going to be a couple of decades.

As this becomes sort of the new normal and what was a secret of success, or it was, "Oh, the first movers,"they're the only ones who knew how to do this stuff.

So they got to collect all the advantage early on.

Once it sort of goes everywhere, then everybody is competing with a more equal playing field. Is that sort of it, just more competition comes around?

Gene: Absolutely. The productivity advantages that are created by using software is now recognized everywhere, and it's not just a back office function, but it's part of-- is about value creation, right?

Customer acquisition, customer retention, achieving the mission. Absolutely.

So the art of software is not just for software companies. It becomes a core competency of every organization.

Grant: Yeah. It's interesting. I mean, I totally believe that, and it makes sense to me.

I guess the pushback is people are like, "Well, we don't want to become a software company."

It's like, "Well, people want to just stay artisanal bread making, but it is better off when there was a little bit easier to produce it more widely, or there's advantages."

Sort of once the sort of mechanization of this new technology gets to everyone, it applies to all these different industries, then it's more broadly beneficial to society rather than being sort of siloed just to the initial early mover on it.

Gene: Yeah. I'm thinking if you talk to people at Tesla, they say they're really a software company.

No, they're an automobile company. Yet one of their core competencies is definitely software that is key competitive advantage to other auto manufacturers.

If you go to Space X, right? Are they a software company? I think no.

They're a orbital delivery company, right. Which software is definitely a core competency that is overturning that entire space transport market.

I would expect if you go to Nike or Adidas, they would say the same thing, right?

We are a sports apparel company or et cetera.

But increasingly, they're all doing billions of dollars of commerce directly to customers, bypassing retailers, and that is a pure software endeavor, and yet I don't think they would call themselves software company, but it is a competency they must have or they must develop in order to compete and win.

Grant: Yeah. No, that makes a lot of sense.

I actually think much in the way that these software companies have made the evolution into and figured out DevOps and figured out that the things I think security becomes a really important part of that as well, because everyone will sort of--

I think in the future, there'll be many companies that are broken by the fact that they did security so poorly and will become a lesson that people learn, where you're like, "Well, in order to grow this company successfully for the longterm, we have to do security right from day one."

You think about it all the time. That's really interesting to sort of the idea that this will spread, and this will become the dominant way of growing any kind of company.

Gene: If I can just add one piece of evidence to support your thesis.

Grant: Your thesis, by the way.

I'm simply parroting it back as I sort of mix it with the things I've thought about. But yeah, this is cool.

Gene: I mentioned that John Willis, a coauthor on the devil's handbook, and independently, very peculiarly, we both read the testimony of the Equifax CEO, and it was interesting. Right?

In preparation, before I read that, I actually read the testimony of, was it Jeffrey Skilling, the CEO of Enron, as he was testifying.

I just want to see where the harder or easier on the Equifax CEO.

I think it was actually the former CEO. In some ways, I thought he got off easy, right?

Essentially, he said it was a technology failure, and that it was combination of human error and a technology failure.

I think in the future, it's not going to be that easy to be able to talk your way out of it, that essentially it is part of your fiduciary responsibility is part of--

You are obligated as the person in charge of the organization of protecting data just as you are about protecting human lives and that people won't be able to be fooled by saying, "Hey, I did my job, but some poor person, right, they made a human error, and there's some sort of technology failure, and therefore, I'm off the hook."

I think they will be much harsher on the next instance, and that regulation and kind of our expectations of people's true responsibilities of security, I mean, that is inevitable and also predicted by Dr. Carlota Perez, right?

That reregulation, that intense reregulation of this new industry and technology.

Grant: Yeah. I think in terms of appearing in front of Congress, like the Congressmen, Congresswomen will need to become more technologically competent as well and will have to know more about security and know about the responsibilities.

It'll be pervasive in where we go. I mean, it is to some degree, and every time we watch one of these folks testify, we see that the other side is ill-equipped to respond to their answers.

They don't really understand the context. So there's not enough depth.

There's not enough comprehension within most of them. Right?

Gene: Yeah. By the way, just what I noticed in both of the testimonies is the people doing the questioning are actually experienced litigators.

So they're very good at argumentation.

But in the case of the Equifax one, it's like, "Oh, you totally pulled that punch. I mean, you had them."

Grant: Yeah. Exactly. Yeah.

Gene: It was just one question away, right, from what would have been, I think an admission of something. I'm not a lawyer.

But to your point, I mean, I think you see the skill and experience that they're bringing to bear, and yet they're missing some knowledge that I think could have led to a different outcome.

Grant: But man, I'm not excited for lawyers to know more about technology. That's not going to be good.

Gene: I'm afraid though that those days are coming. Yeah.

Grant: Yeah. It's inevitable. Amazing, Gene. Thank you so much for spending time with me.

I really do appreciate it. Thank you for your contributions to the entire ecosystem and DevOps and everything that we're doing.

I always pay homage to the folks that came before Replicated because we really came into an industry that was very quickly automating.

So the work that you've done to sort of accelerate that is hugely valuable, and I definitely appreciate it personally.

I know the rest of the ecosystem values, the work that you've done. So thank you.

Gene: Oh hey, my pleasure and congratulations on all your successes, and I look forward to hearing more great news about you and team in the future.