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
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.
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
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
So think back to the late '90s.
That's the time of the dot-com boom is the rise of e-commerce before the
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.
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
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,
That was really a well-defined
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
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
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
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
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
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
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
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
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
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 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
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
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
Then I loved the idea of being a
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
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
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
He was having to deal with all the consequences of
promises made to organizations to get the deal.
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
But it's another kind of an interesting reflection I've had lately is now
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
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
Gene: Around 350? Around
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
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
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
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
He was talking about how they
did a specific part of the SolarWinds
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.
So in other words, I think our cost of sales and marketing at that time
was around 60%.
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.
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.
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?
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
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.
I mean, it was just this incredible vibrant problem-solving that
took part over three quarters of a day.
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.
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
Sorry, Safe, which has been prioritized by
So some people would like to
But I mean, there is no doubt that those forms, that
philosophy, that level of engagement throughout the company, I mean,
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.
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.
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
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
It's just like how the ecosystem works.
Gene: Right. Absolutely. It's my personal observation, and it sounds
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
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
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.
The whole time, he was apologizing saying, "Oh, I know there's a better way to do
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
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.
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
We got trained, just at least in the fundamentals
of UX, how to design products that don't hurt
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
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,
Just usability as a feature.
It's an interesting insight, right, where we often lose
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.
You got in there, and you delivered a better experience, I assume.
Gene: Yeah. Oh, for sure. Right. I think they have that meme,
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
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
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
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
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.
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
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
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
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,
She's entirely stuck, unable to do anything
by herself. It means that you can't onboard
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
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
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
Gene: Oh, for sure. I think we're just at the tip of the iceberg in terms of where we should
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
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
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
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
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
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
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
fantastic because it not only helps the company, but it certainly helps that person,
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,
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
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
Right? I mean, these are all people that we identify
as experts at their craft.
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.
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
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
It's not something you can do through a blog post or in a talk.
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
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
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.
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
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
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
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
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
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
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
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.
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
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.
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
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
I always sort of say, I think that there's this
relationship that enterprises have with the data that they touch
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
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.
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
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
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
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
100 years ago, there were a hundred car startups in
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
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
So they got to collect all the advantage early
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
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.
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
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
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."
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.
Gene: Yeah. By the way, just what I noticed in both of the
testimonies is the people doing the questioning are actually experienced
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
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.
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.