Dan Croft - Former Director of Engineering Productivity at GitLab

Dan Croft, former Director of Engineering Productivity at GitLab, sits down with Ryan to walk through his career, discuss his perspective on open source software, and talk about his approach to hiring and being hired.

Connect with Dan on LinkedIn: https://www.linkedin.com/in/danielacroft/

Episode Transcript

(00:00):
Welcome to the Good Fit Careers podcast where we explore perspectives on work that fits. I'm

(00:08):
Ryan Dickerson, your host. Today's guest is Dan Croft. Dan is the former director of engineering
productivity with GitLab. GitLab is a publicly traded open source software company that generates
$425 million in annual revenue with roughly 1600 employees. GitLab is a Y Combinator company with
both Ukrainian and Dutch founders. The GitLab product is an open source dev ops software package

(00:34):
that enables the development and operation of secure open source software. Dan, thank you for
being here. Hey, thanks for having me, Ryan. Delighted to have you on. So I find your work very
interesting. I think the concept of GitLab and open source software is very interesting to the
rest of the world out there. Would you share a little bit to start about what your job actually

(00:55):
means as the director of engineering productivity? It's a super interesting role at GitLab. It's
unique in a couple of ways and we could talk about that separately if you like, but basic idea is
like helping team members at GitLab be as efficient as possible across engineering is kind of the key
focus. And that's a big part of what we do. Roughly how big is your team? Where do you fit

(01:18):
within the organization? Right now, six, we have one open position. We're hiring. And our team
reports into the VP of infrastructure who reports into the CTO. So going back to your roots,
the beginning, would you tell us a little bit about what you were like as a kid and perhaps a
bit about what you wanted to be when you grew up? I'm laughing because I'm just picturing my siblings

(01:44):
answering this question instead of me. That might be a different answer. But yeah, so I'm one of
six kids. I've got two older brothers and three younger sisters. I grew up at a place called
Mount Nebo in Australia. It's in Queensland, which is sort of a north eastern state in Queensland,
in Australia, excuse me. I was in the bush. My growing up was playing in the bush and trying

(02:06):
not to get bitten by snakes, jumping in waterfalls and all of that kind of stuff running around.
It was pretty fun. Heavily into sports, I competed in cross country running. We grew up pretty,
not well off is probably the best way to put it. We're on a single parent, mom was on a single
parent pension, raising six kids. And so that was my childhood. What did you want to be when you

(02:30):
grew up? Did you, an astronaut, a scientist, a paleontologist? I had no idea. I did collect
rocks when I was really little. I had a rock collection and then I was also collecting cactuses
at one point. Cacti. I like to mispronounce it cactuses. But I don't actually recall for a while
I wanted to be a police officer and, but didn't really have any, like, I want to be an astronaut

(02:53):
or the, you know, prime minister of Australia. I never really was that focused on anything like that.
So then your early life, your education, it sounds like sports were a big thing,
enjoying the outdoors, just kind of doing the Australia thing, trying not to get killed by
all of Australia. School was school like for you. School was pretty interesting. Where I grew up,

(03:14):
school is very small. And so we had sort of a demountable building with two classrooms. And
that was all of primary school in Australia. That is grade one through seven. Grade eight is the
first year of high school in Australia. So that was like, I think it was like 30 to 50 people in
the school. It was tiny. Yeah. You had another part to that question. Did I miss something there?

(03:34):
I apologize. Yeah. So kind of that transformation from that early education through high school
and then into, into university study. Yeah. What's that like? Yeah. So tiny school and there's,
you know, sports and stuff as well. But I also got very interested in like history, different
cultures. And, and I particularly was interested in, um, uh, like Russia for some reason, I think

(03:57):
it was the Zars and that's Zars. I'm probably mispronouncing that, but I've kind of got the
history of like being interested in like super interested in China and, and, uh, Japan and like
a lot of these countries that in India that have these long, long histories and different cultures.
So I went into high school. I don't know how my mum managed it, but my first year of high school
was in a private school. I have no idea how she managed that, but we did six months of German and

(04:21):
six months of Japanese. And so I studied Japanese once I went into college. High school was,
we'll go into that later. We call it university or uni, but high school was interesting. I was one
of those students who's like, when I'm interested in something, I'm very, very good at it. And when
I'm not, I'm not very good at it. So like in grade 11, I got the ancient history award for my whole

(04:44):
high school. I was in musicals and I was in sports and competing and stuff, but, and then I like
failed another subject because I just didn't care about it. And that was always been kind of like
that. And then going into uni, I went into a bachelor of arts in modern Asian studies and I
was learning Japanese and the idea in Australia, very connected with Southeast Asia and Asia in

(05:08):
general, just proximity wise. And so I was thinking sort of business moving in that direction,
but a lot of it was cultural and learning languages. And it doesn't sound like software
and engineering productivity was quite on your radar yet. Nope. My transition transition into
working in, in computers was kind of weird. My first ever job was, I was a gopher at a law firm,

(05:34):
meaning that I would take a legal brief and literally run across the city in Brisbane to
deliver it to the court on time. And that was my job and I've run and run back. And
how did you get that job? I did work experience in Australia. We do work experience in high school,
usually in grade 11. You do work experience. And I was, I think at some point I decided I wanted
to be a lawyer. I started working in a law firm and decided I didn't want to be a lawyer. And so

(05:58):
I just, I was like work experience. And then when I got out of our school and I wanted to move out
and be self sufficient, I reached out to that same firm, which was Nickel Robinson and Kidd in
Brisbane for whatever it's worth. And the CFO said, yeah, come in and work on stuff. And that's
kind of the first role I had. Interesting. So work experience in this context would be like the co-op

(06:19):
concept here in the States where you're still in school, but you're doing kind of an internship
and you're doing a little bit of the work while you're still studying. Yeah. And that's kind of
like, Hey, I think I might want to be in this career and it gives you a chance to see what it
looks like. And you're not a lawyer now. How did it go? Yeah. Working in a law firm for a while
makes you go, I think for maybe for a lot of folks, you go, I kind of want to be a lawyer or I don't.

(06:42):
So that was more for me. What ended up happening there was the office manager, Albert Healy,
is his name. He's actually the honorary counsel of Malta, which I always remember. But he was like,
Hey, do you want to start helping out with some other stuff? And I was like, sure thing. No problem.
I was in the mail room and running briefs and whatnot. And then one of the things they wanted
help with was the IT person there. They had Weiss mainframes. It's funny how I remember this stuff.

(07:08):
Forget a lot of things, but apparently I remember this. And so they had like dumb terminals and all
of that kind of stuff. And so I started learning how to set all of that up and configure it. And
then eventually they bought a PC for their library computer. Cause a lot of law firms,
they used to get distributions on CD-ROM. And so they always maintaining that and they wanted

(07:29):
a computer cause it didn't really work with the dumb terminal model. And my favorite story related
to that was like, yeah, why don't you take over this? And then I got it. And I think the day that
we got the computer, I dropped it on the floor. Oh, I was setting it off on the desk and I just
didn't have it slide off. Such a good time. Did the computer survive? Yes, it was, it was a

(07:51):
little worse for web. It still works. Thankfully. That's awesome. So you started out like setting
up the computers kind of being more on the, I dunno, would that be networking or like setting
up the infrastructure? Is that how you describe it? For that role, not really. It was really just
maintaining a PC that the organization needed and then helping out continuing to do all the other

(08:12):
stuff that I was doing. Sure. And what year was this? '93 or '4? Question mark. So it's, you know,
in the mid '90s here, we haven't had the millennium yet. We haven't had the dot-com bubble. What did
software look like at that point? It certainly depends on your industry, but it's all that old

(08:32):
school stuff. It's not like the internet was super popular then. It's not like the internet was a
distribution model that you could rely on or look at using. So from those early days, my recollection,
and I've actually worked in a lot of law firms over the years in different capacities, particularly
in that type of industry, there may be a little more risk averse in terms of the types of things

(08:53):
they get involved in. And to be frank, you know, my experience of it in that particular role was
like, I got a CD, I made sure it was installed on the computer and then it was like, cool, whatever.
And then I'm a pretty curious person. So I was like, oh, what is this? How does it work? And I'm
poking around with it, of course, because that's part of who I am. So yeah. Interesting. Just the
curiosity was driving the learning. That makes a lot of sense. So then kind of late '90s here,

(09:17):
it looks like Web Central was one of your early jobs. Yeah. Well, the funny thing is, I think
what's interesting for me to compare it to a lot of folks that I work with and have talked with and
all of that is I didn't own a computer at all until I was in university. So I never owned a computer,
I never touched one. I'm not like one of those people is like, I had a Commodore 64 and I was

(09:39):
writing games or whatever when I was four. I'm like, nope, I was out playing in the bush and trying
not to get eaten by snakes. So like my dad bought me a computer when I went into uni, which was
awesome. And the first thing I did not knowing anything about static electricity was pulled the
whole thing apart down to the motherboard and everything, put it all on my carpet because I'm

(10:00):
very smart like that and then put it all back together. Everything was fine, by the way,
but it's just like now the visual in my head of having it all on the floor going, yeah, okay,
I pulled it apart. Let's see if I can put it back together and not even realizing that I could just
destroy it on the spot. One little whoopsie. Exactly. I was like, eh, maybe you call that
dumb luck, but whatever. But yeah, there was curiosity really there and then that's really

(10:25):
what led to me getting involved in computers. And so Web Central was really like, I forget how I
made the connection, but Web Central started as a support role, just like answering calls. I used to
do night shifts to be on a support team. All of that type of stuff, pretty normal for a web hosting
company in early days for a web hosting company as well. And they started out as PowerUp was an

(10:49):
actual in ISP and PowerUp and Web Central were like the two partners created both of those
companies. And so there was this sort of historical ISP stuff going on as well in part of the company.
And then the web hosting was like all straight web hosting. We had a server room with racks and all
of that stuff sitting back there. How exciting. So let's fast forward a little bit here. You've

(11:11):
been in the software, the internet world for a little bit. What did you have to learn to really
become proficient or dare I say an expert at what you do? What was perhaps difficult for you to really
master? That role sort of converted into like issue development role in supporting hosting customers.
I started trying to help them with code problems they were having in the environment. So I started

(11:34):
digging into code and that was mostly cold fusion at the time, which was pretty hilarious. And so
that was just more curiosity driven as well for me. I was very curious about how everything worked.
And when customer had an issue, I'm like, Oh, okay, well, how does it, what is going on? Let me go
figure it out. Got into databases and all that sort of stuff. I think when I started working at
like Dawson Waldron, I was hired into be a software engineer effectively. And that was writing a

(12:00):
training software from the ground up, like was just me doing it all as a separate kind of entity
within the law firm called legal practice technologies. And one of the products they
made was training and using lawyers experience, but like, like refining that into a training
product that customers could install. And that was everything that was front and back end database.

(12:21):
I was writing in VB, like original VB and SQL databases and all that stuff. And that leap is,
that was a thing, right? Like going from like, Oh, I help customers with the things to I'm writing
a product by myself and I don't actually have any help. It's like, how do con components work? You
know, like what is even a SQL database? What's normalization? How much should I care about?

(12:42):
So it's, it's going from sort of a hobbyist mode to being like a, you know, customers use this.
And if it breaks or it doesn't work well, you still got to fix it. Right? Like, and it's
preferable to do it right first or do it well enough first. Maybe writes the bad word.
Yeah. Oh wow. How exciting. And so when you're thinking about the, the, the work you were doing

(13:05):
within Blake Dawson and then Piper Rednick, these were both law firms, right?
Yes.
What were you, what did they want to accomplish at that point? This was the 2000 to 2004 kind of
timeframe.
Yeah. So the legal practice technologies team was founded by Liz Broderick, was a lawyer at
Blake Dawson Waldron. And then the basic premise of that team was like using technology to provide

(13:28):
services that are unique to a law firm. And so the, the, the technology was really just sort of
a platform, a delivery mechanism for this specific training that would be more available. Like it was
HR training and sensitivity and like stuff that relates to liability. We have so many products
in the market that do this now, but that was kind of early days for that.
Piper Rednick was a different role. That was definitely, that was more around the handling

(13:54):
of documents that are responsive in a case. So that was a really very different role.
And it wasn't my first job moving to the States. That's where that change was. I was living in
Australia. I moved to the U S in 2002 and got a job at a small company, uh, Citigate, Cyber Binin,
or Cyber Binin, which was a PR company. And I was, I was helping the IT manager just with everything

(14:17):
and every anything at the company. And that was super interesting as well.
So let's fast forward, you know, 15 or so years, let's call it 2019. You're just about to land at
GitLab. What's, what's your world like at that point? What are your thoughts on software engineering
and why GitLab and what was that like? That was a rough time for me. I had been let go from one job

(14:41):
and then I had, had sort of agreed to leave that the next role I had, which is really hard.
Cause it was after I got let go from simple reach, I really considered just not being in software
anymore. Cause I was just feeling so down about the whole thing and hadn't yet come to terms with
what happened and how to sort of rationalize it all. And so I actually took a job as a operations

(15:04):
manager for an operations person for a coffee roastery. Cause I've been obsessed with coffee
for a very long time. And then this role with socially came up and it seemed like the, my
dream job of like helping build culture to be high ownership. And it was really exciting. And the,
the CTO there, we had great chats and it was very exciting. Um, and unfortunately it just didn't

(15:26):
really work out, but in combination, those two in a row was just like extremely difficult. And
it's a low point, but you learn from all those low points, right? And it took, it took me less
time to learn from the second low point and it did the first one. So that's an improvement, I suppose.
If I may, if, if anyone out there is listening who feels the friction, perhaps that you were

(15:49):
experiencing at that point, what would you share with them or what did you learn about the awareness
or recognition, the things that weren't going so well? I think even though, and I don't want to
speak for anyone involved, but I think even though you can kind of say what you want, it doesn't mean
that that's actually what you need or you want either. So like as a, as a sort of a leader in an
organization, you go, ah, we need to be this, or I want to achieve that. But in execution, when you

(16:16):
start actually working through it, you can kind of realize that it doesn't really gel with what's
going on and adapting to that could be really hard. I think one of the biggest lessons, and we'll
probably get to this later, is just like understanding alignment and what alignment
looks like is like super, super critical. Like, and that's hard, like, especially when it's like,
Hey, I want you to do this. And I'm like, yeah, I'm super excited about that. But then there's

(16:38):
a bunch of other stuff you need to do as well. I'm in figuring out how to like balance those things
out can be really difficult. So communication and alignment. Something that I, I spend time
working with my clients on is helping them think through, you know, really, is this a good fit? And
I come to find that often the people around us are much more able to identify that it's no longer a

(17:00):
good fit. If I've become the sour grape, or I'm, you know, grumpy every day or whatever it is, or
my partner knows that I come back from work just pissed, you know what I mean? It's, I find it so
interesting. It's so hard to see in the moment. And I commend you for seeing it, addressing it,
and growing beyond it. That is that is not an easy thing to do. Yeah, it's hard too, because I think

(17:20):
it's sort of almost, I would argue it's kind of human nature to sort of demonize people,
because it helps you just kind of move on from whatever it was. And I've certainly done that.
So I'm not going to sit here and say I'm, you know, perfect pants person. I'm not. But I definitely,
in retrospecting about it, like, what can I take away from it as really what that was. And there's

(17:41):
certainly positive aspects of that role. I'm not, it's not all doom and gloom. Yeah, it's worthwhile
sitting down. We retrospect in technology for a reason, you know, we try to do blameless
retrospectives for a reason so that we can learn from it. So yeah, doing that personally can be
pretty challenging at times. No kidding, no kidding. So on the way back up here into another good fit,

(18:02):
what was it like getting hired at GitLab? And what was that first engineering manager role like?
It was a funny story. I didn't know what GitLab was when GitLab reached out to me. Like everyone
knows GitHub. Lots of folks don't know what GitLab is. And perhaps for the listeners out there,
would you, would you regale us? Would you tell us what exactly it is? Oh, yeah. So GitLab is a

(18:23):
DevOps platform, DevSecOps really, we're trying to integrate all of the DevOps components, but also
add security to that. Because these are really key considerations. It's an open core product,
which means you can contribute code, please contribute code, because we really like it.
And that allows really, it's a single stop shop and allows us to deliver things in ways that aren't
really possible when you're doing integrations. So that's one of the key points that we sort of make

(18:47):
compared when folks are shopping against maybe Atlassian or GitHub or whatever, is that integration
could be super, super powerful. Perfect. And thank you for the detour. Yeah, tell us the story.
Yeah. So I'm like, I'm not without a job. I'm feeling pretty down. And my best friend goes,
hey, I was interviewing with a few companies, one of them was this GitLab company. And I was like,

(19:09):
huh, okay. He's like, I gave them your name. I don't think I'm going to take the role. This
friend of mine ended up at LightStep, which got acquired by ServiceNow. And so it still works
there. And so GitLab recruiters reached out to me and they were like, Hey, we, someone referred you
to us. And so you want to have a conversation? I'm like, sure, nothing to lose over here. I don't
have a job right now. I'm feeling terrible. Might as well give it a try. And ended up doing pretty

(19:35):
well in the interviews and got the job that was sort of as GitLab was just going into the hyper
growth sort of phase we did through 2019. And what was interesting is you, because of the way
it was growing, this was true for a lot of companies. It wasn't like, this is the role
we're hiring you for is like, hey, we're hiring EMs, we'll have various teams, maybe it'll be
this one. I ended up getting hired as the engineering manager for the package group.

(19:59):
GitLab, you have group and stage stages, like a slightly high level. It's lined up with the
product stages and the DevSecOps lifecycle. And so they hired me in at the time, the product manager,
Tim Rizzi, who's a total legend. I hope Tim hears this because I'm such a big fan of Tim,
was already there. And then I showed up like, question marks, I don't know what a GitLab is.

(20:22):
And so like, my goal was to hire a team and get us moving towards this stuff that we had to work on.
And that was package management, like Maven and that type of thing. And also the container
registry, which is the Docker distribution registry. Zero people in the team other than Tim,
when I joined, a couple of folks had been hired, but hadn't started yet. And then I had to hire

(20:44):
the rest of the team, which ended up being six people. So before we get too granular here,
would you tell me a little bit about perhaps who uses the GitLab product and a little bit about how
they use it? We don't need to go into specific example, but I'd love to get a sense of roughly
what I or anyone else out there might use this for and how they would use it.
The types of customers kind of span the whole gamut. We have free users of GitLab that just

(21:09):
individuals who want to write code and have a platform to do it in, because a key component of
DevSecOps is source code management. So that's a key component. We can issue tracking,
what are we working on? A lot of the stuff that folks are familiar with. But also we have CICD
pipelines, deployment, monitoring, all of those stages. And I could refer you to GitLab's homepage

(21:31):
to get that in more detail. But the types of customers we have range from those small,
free individuals trying to work on code, or maybe it's just personal projects. Maybe they
have a product. So big corporate enterprise level customers who are doing very interesting
stuff that goes beyond the product and into the API and building their own tools and those sorts

(21:53):
of things. But it's really intended to provide a single product that allows folks to walk through
an idea through to development, delivery, and monitoring and maintenance for any kind of
software project you want to work on. Wow. That's much more broad than I would have expected and
much more flexible than I think I had imagined. Yeah. It's pretty big. When we say DevOps likes

(22:15):
lifecycle, I think I don't want to compare it to other companies, but we generally mean it when
we say that. There's a lot of aspects to the GitLab product. And as I've worked here for a little
while now, you realize you can deep dive on all of them down to a very granular level. And because
we're super transparent and GitLab's infamous famous, depending on how you look at it for being

(22:39):
super transparent, you can go look at the issues we're working on a lot of time and see people's
MRs and which is your PR for GitHub folks. Okay. So now you're in the engineering productivity
role. And let's just say we're going to teach the audience a little bit about what you do and
provide a little bit of education here. Let's say I'm a new member of your team. What's one of the

(23:00):
more challenging things about the work on your team? And could you perhaps walk us through or
teach me how to be a good team member and be productive in your group? I think one of the
challenging aspects is that there's a lot of scope with this team. And as I alluded to earlier,
the difference with a productivity or a platform team, however you want to think about it, at

(23:22):
GitLab is that GitLab writes the tool we use to write GitLab. So that means that you get products
like backstage.io type thing to enable engineers to test out projects and know how to have templates
for whatever it is. That can be your productivity team or a developer platform team, however you
want to look at it. But at GitLab, that's the product. And we have product development groups

(23:46):
that work on those things. So a lot of what we do in our team is actually implementing product
features. And in a way that supports the unique use case that GitLab as a company has, as distinct
from GitLab to product. And so coming into that as understanding there's a good bit of infrastructure
and it's part of the reason why we're aligned with infrastructure. There's a good part of

(24:08):
infrastructure understanding, deployment knowledge. Pipelines are a key focus that we have. So coming
into the team, really there's a really broad scope of work that we're responsible for. And so as a new
person in the team, it's really just making sure that we can focus on what's necessary, but also
then branch out and start learning about how these things work. And that overlaps with the

(24:31):
implementation that we use as well as the product features and how they work.
That makes a lot of sense. So let me repeat back what I'm hearing. It sounds like the
GitLab platform and product is both what you are building and selling, but also how you are
building and selling the product. And so as you guys come out with new features and capabilities,
it sounds like you need to learn how to use those, give them a try in your own specific use case for

(24:56):
building the GitLab tool or the platform broadly. And I imagine that would be a fascinating way to
debug and test and find the flaws and be like, "I don't know how to use this thing. What are we
doing here, product guys?" If you look at our handbook, one of the big things that we have in
our handbook is dog feeding. And compared to some other companies that maybe that's not what they

(25:18):
do is not really aligned with the product they produce, which is fine. That's a normal scenario.
We all use our product. And so one of the scenarios that I think is pretty fun is that in instances
where there isn't a capability in the product, we'll go build tools. So it's not just sort of
implementation and support. We also actually build tools. An example of that is our TriageOps project.

(25:39):
Ideally, it ends in the product. We want to make those features available. We have customer
requests for it, but it was just solving a problem that we had at GitLab to help folks understand
where their labels were at, what they should be aware of in terms of the work that they had
outstanding, things that were sitting in a backlog that maybe should be scheduled or whatever,
that type of thing. So we have various tools like that that we built and we operate independently

(26:03):
from actually just implementing and sort of supporting product features that we're actually using.
That's fascinating. Thank you for diving into that.
If you've experienced the layoff, are working through a succession plan, or will be packaging
out of your current company soon, please feel free to reach out, subscribe to my newsletter,

(26:27):
and follow me on LinkedIn for insights and advice that might be helpful in your search.
If you'd like more direct assistance, please go to goodfitcareers.com to apply for a free consultation.
So you're in Utah, you have team members all over the planet. As far as I understand, GitLab

(26:50):
operates in an asynchronous work environment. What is that? And what was it like adjusting
to that new paradigm? Pretty fun, actually. Very challenging, but in the best kind of way.
So yeah, we never really optimized for hiring in specific locations, except when there's support
requirements, different teams have different needs in terms of we need people online,

(27:13):
and then it's better to have people spread out. There's some very interesting pros and cons to
that. You can have the fun example I like to use a lot is if you have an MR, you're trying to write
some code. You push the code up and you need a review. You're like, "Hey, can I get a review?"
And the person that reviews it is one direction, as far as the sun goes, or the earth rotates,
I guess, or the other direction that can have a big impact on when you get feedback. And it's not

(27:37):
necessarily one way or the other. Because if you get to the end of your day and you ask someone
in APAC to do a review for you, that's the start of their day. So great. It gets done right away.
If you ask someone the other direction, then maybe you end up having a longer wait 12 hours or
whatever until they come back online. So you can average that out over time, but maybe you want to

(28:00):
optimize for that and say, "Well, let's send reviews one direction with the sun." So that's a very
interesting factor, but the asynchronous aspect is different from time zone distribution. So the idea
of asynchronous is that you need to write everything down. Otherwise, it's really hard to maintain
context for anyone that's trying to become involved. This is an actual issue for every company. It's

(28:21):
every organization, different solutions everyone meets, or whatever we share a time zone. And we
just went in one big direction with that, which meant that we have different ways of approaching
things. The fun example is standups. For software engineering teams, you do a standup. Often,
people like to do scrum and each of their own. We could talk about that some other time maybe.

(28:43):
When is morning? If your team is spread around.
It's always morning, right? Somewhere.
It's always not. Yeah. So when is morning? So one of the fun things that we've figured out is you
can do asynchronous issue updates. So you're working on an issue. It's assigned to you.
Maybe there's some code associated with it. You could just do an update on that issue.

(29:03):
And then when anyone's interested, remember those issues are visible to the public and
customers and everyone. Anyone that's interested in that project and that work that's going on,
they could go look at the issue and see what's happening. Even if you don't do that, for a lot
of the stuff we do, I mean, security releases, of course, we have a separate process. And that's
absolutely something that's necessary. But it means that if you were curious about what my team is

(29:27):
working on right now, you could go into GitLab. You could go look up our team and see what issues
we're actually working on. And even without the asynchronous issue updates, you can actually go,
most times you can link through that issue to the MR, the code that someone's working on,
you can actually see the code that they're working on day to day. So the transparency value is a key

(29:48):
part of that making async work and high context and allowing folks to understand what's going on
and discover it. The con of that is there's a lot of information. There's a heap of information.
You got to read a ton, I would imagine. Yeah. So it's like finding the stuff that's useful
and important, urgently important if you want to use the Eisenhower model or whatever at the right
time. And for those out there curious and perhaps a little bit more nerdy on the engineering side,

(30:15):
do you guys run Agile? Are you running Scrum teams? What's your methodology?
Well, historically, we've kind of done whatever the EM wants to do as far as making sure the team is
productive. And so I might comment on the EM would be an engagement manager, right?
Thanks. Sorry, I won't use acronyms. Engineering manager. Thanks.
Just want to make sure everybody else is on the same page as I was.

(30:38):
It's in our handbook. We shouldn't use acronyms. So I apologize. But you did say the nerdy
version. So yeah, so historically, what we've done is we've kind of had to we've defined the
metrics that a team is trying to deliver, and then we sort of work off the metrics. And so
what that means is whether you want to operate like really, really strict Scrum or some very

(31:02):
strict version of Agile with lots of ceremony in it is kind of up to you. And it's when you're
hiring the team, a lot of that comes back to like who you're hiring and what they're able to do
that's aligned with their strengths, right? So we've certainly over the years had different
people running different levels. I tend to be a big fan of Kanban or Kanban as sorry,

(31:25):
terrible Aussie pronunciation. Maybe it's just me.
Tomato.
I've been a big fan of that because it lets you adjust. But as you kind of move into more of this
enterprise space, then generally you want to see more predictability. And so leaning a bit more on
ceremony can help. The thing is with some of that ceremony, it can be a little incompatible with
time zone distribution. And so that's where folks end up, I think having like variations on that.

(31:50):
But in the handbook, we're kind of very much on results oriented work, which is talking more about
what we're delivering and when we're delivering it. And so that will drive people to improve or
change their processes as appropriate. Generally speaking, we have good structure around releases.
And so whilst we have iterations that we would associate with a monthly release cycle, some teams

(32:12):
go for like two week sprints or maybe even one week sprints. Some teams just keep it aligned with
the milestone releases that we do, which we've been doing consistently for like 10 years straight
or something like that. So thinking about somebody who might be in school today studying computer
science or thinking about trying to break into engineering management per se, are there

(32:33):
methodologies or techniques or modes of operation that you would encourage them to learn more about?
And perhaps, you know, waterfall used to be the legacy and then it was agile and you know,
where are we headed and what might be worth learning or leaning into?
Well, it's funny as I see all these YouTube videos going, maybe waterfall was right. And I'm like,
okay, this is probably just algorithm work from the future.

(32:54):
The values are back.
Yes, yeah, throwback. That's what I've got the mullet doing it, doing it right.
I mean, where I'm at right now, I feel like it just depends on the stage of the business.
It's good to have some sense of what is effective in my experience. Great problem.
But if you're at a tiny startup, it's got like five people and you want to introduce all the

(33:16):
ceremony, then it's probably not super practical. It's really just making sure you understand the
needs of the organization. And it's less about specific skill sets and or about like understanding
the needs of the business and that need of the business is really the needs of your customers.
So thinking back through some of the projects that you've worked on, you've done incubation

(33:37):
engineering, engineering productivity, you've been on the CI and CD team. Are there any projects
that you thought were particularly fascinating that you'd like to share?
Yeah, I always go back to the container registry work. This is pretty fun, super interesting work.
We had a product, it's called container registry, but it's a fork of the Docker distribution

(33:57):
registry from Docker. Well, formerly Docker anyway, it's moved over to the ETF or I forget the
acronym, but I don't even know, I forget what the acronym is. So I apologize for the acronym and
also not knowing what it is. So what we were doing there is like, this is a way to store Docker
images. And the way it works historically and still works as far as I know, it's all file system

(34:21):
based. This particular product offering a GitLab is sort of a separate service, which is fairly rare
because we generally are monolith at GitLab and everything's in Ruby. Monolith meaning you only
have one big code base for folks that are used to that terminology. They asked that we had when I
joined GitLab was let's work on it. You own it. Okay, so what are we doing with it? Okay, what are

(34:41):
our product plans? Our product manager was key in that. The key decision that I had to make before
I even had anyone on board to do the work, which is not ideal because I had never worked with it
either. And I hadn't worked with Ruby for like six years before I joined GitLab because it wasn't
exactly me that was going to go get in there and bang out some code right away. So we had hired a
bunch of people. I realized we had a conversation about how we're going to move forward. And I had

(35:05):
employee number one and one of the founders and among several others are really key folks at
GitLab having a conversation about how we should move forward with the product, whether we should
build our own, whether we should use a product that was already in market, or whether we should
fork the thing we already had. There's a key problem we were trying to solve, which was we're
using 10 petabytes of data. And it was costing us a lot of money, as you might expect. That's a P,

(35:28):
petabyte. It's a lot. And so basically, we kind of worked through this and it ended up being a split
decision. And I had to make the decision on what we were going to do. And so factoring...
The future of the company, right?
Yeah. And so factoring in all of the things, I'm like, well, this has already got a bunch of
learning in it. And so I made the decision to fork Doctor Distribution Registry. And then I had to

(35:49):
folks that hadn't started yet, or Ruby folks. And I had to make the case to hire two Go folks instead.
And so I had to relocate them inside GitLab, which is great. And they're still here, actually,
which is awesome. And then I hired two people to do the work, both of whom are incredible.
Shout out to Jourame and Hailey, just total legends. They did it. They wrote online garbage

(36:12):
collection into the Doctor Distribution Registry as a separate fork. And that saves $6 million
a year or whatever for GitLab and data storage. One of the hilarious things about this is...
It's not really hilarious. I just find it very, very amusing. Along that path, because it took
some time to be fair, which is expected, along that path, we actually were working with our

(36:34):
self-managed customers, because GitLab is one of the companies that still does self-managed as well
as hosted. And we're moving into dedicated and other environments now as well. One of the points
along this path was one of that team did work to do performance. They did performance improvement
work on the offline garbage collection, because some of our larger self-managed customers weren't

(36:54):
able to run offline garbage collection, which is cleaning up stuff that's not used anymore.
I think it's in the offline state, and they were getting to the point where they couldn't run it
because of the size of their data in a whole weekend. So these large customers wrote a point
where they had to have downtime no matter what. And so the side point for this whole project was

(37:14):
this person managed to improve the performance of the offline garbage collection by 90%.
And that's a footnote.
That's a staggering improvement.
Huge improvement. And it's funny talking with this person, and I've mentioned a few people,
but I don't want to keep mentioning names, but talking with this person is like, "Yeah, I feel

(37:37):
like the big achievement here was online garbage collection." And then the side point maybe is this
thing. And I'm like, "For a lot of people, that is the big achievement. And it's a huge achievement.
So great work. Excellent."
The modesty.
Well, realistically, it's a bit of modesty, but it's also a recognition of the fact that
that online garbage collection project was massive and hugely impactful for GitLab and our customers.

(38:01):
But also it doesn't exist. This was a team, a very small team implementing something you needed to go
to Docker trusted registry in order to get. And so we actually forked it and created it.
And now that's part of GitLab.
That's so fascinating. Amazing how these things evolve and come together over time.
I mean, what a wild one. When you're thinking through software, open source, closed source,

(38:22):
what the world thinks about as software. Can you tell us a little bit about how you believe
the world perceives open source software and the development therein?
Yeah. I mean, I think the classic answer for any question is it depends, right?
It always depends. As has been shown, look at the space wherein you've got GitHub and GitLab and

(38:46):
Atlassian and other other product companies. GitHub is well known as being the place you go to go
write open source software. But GitHub is not open source.
It's Microsoft, right? I mean, that's...
Yeah, but it never was, as far as I recall. I mean, I could be wrong now, am I being corrected?

(39:08):
But GitLab's open core, but maybe we're not perceived as being the place you go if you've
got open source software. So open source is like you get to see everything and open core is the
idea that the core components that we sell or you can get for free are all visible, available,
and you can contribute to them. That's the key difference. There's some functionality that we

(39:28):
keep in separate branches that we charge for. And so there's this distinction between open core
and open source. It's like a slightly limited version.
So when you think about how the world sees open source software, are there misconceptions or
things that I might not know about open source that you now know, given your inside track?

(39:49):
It's hard to know because I've been living it for five years. So I feel like I'm very
not aware of how people perceive open source or open core software at this point.
What I do know is that, I'll give an interesting example. I think there's a lot of cases where
people think of open source as being like, it's like all the people with Linux and those people,

(40:10):
it's for neckbeard folks or whatever you want to kind of characterize it as, right?
That's not very nice.
I mean, I'm not that far off. So don't worry about it.
I mean, rocking the mullet, I hear you know.
I'm like, I'm inside this glass house. I'm throwing stones at it. It's fine.
Fair enough.
But like, you can actually see from some of the interactions that we've had,

(40:34):
how like at one point we tried to introduce some closed source tracking software into our front end
because we needed some data to help us make decisions. And there was this, it went on
Pack and Use that we had thousands of people in there commenting on it. We ended up having
to lock the thread because there were death threats and it was ridiculous. Like it was,
it was, it was very not cool. Some of the people, but we also had a great conversation with the

(41:00):
community going, I think this is a bad idea. And a lot of us felt that way too, but we're trying to
solve a business problem. We're trying to be a successful business. So you've got to balance
some of those things out. So in cases like that, where you have this open core, and this extends
more into even the transparency value of how GitLab operates, the opportunity to even have that
conversation does not exist in most places that you're actually purchasing software from or like

(41:26):
interacting with. So what seemed to be missed in that very, for a while there was actually a lot
of great feedback, right? Like, so I don't mean to characterize everyone as being like, not cool.
Sure.
The way that we're communicating.
But it sounds like someone got pretty spicy.
It did. We've had to, like, we've actually had issues and part of that comes from the transparency.
But in that case, like what you get to do is actually give feedback, be part of the process.

(41:51):
And so I think that there's this sense that maybe open source has this kind of like very nerdy,
super techy kind of approach to it. But when you see companies like GitLab doing things out in the
open, it is an opportunity to contribute and learn way more about how everything works and learn from
it. Like, you can go look at the code we're writing. And so I think from that perspective,

(42:14):
we're not the only ones, of course, but like Patchy Foundation is another one where you get
to look at a lot of these things.
Yeah, Patchy Hadoop would be one of the bigger products there. Is that right?
Yeah.
Yeah. And you've got like huge, huge corporate enterprises that are actually using this software.
So I think that it sort of depends, like I said, so like both of those things are true at once.
And so I don't know what folks have in normal, everyday, non-GitLab people have in terms of

(42:41):
experience working with open source. So I don't really know which spectrum that falls into part
of the spectrum that's in, but yeah.
Yeah. And I think the answer that I'm hearing is it's complicated, right? I mean,
this is just much more of a broad and dynamic question than, you know, what does everybody
assume?
There's the free as in beer kind of argument, right? And that's where if you, I think if you

(43:04):
spoke with someone that was hardcore open source, they'd look at GitLab as being not really the same
thing at all. So there's definitely different perspectives in a sort of more technical space
about what open source, open core free software really means. And so that's a whole other
conversation that I think most folks wouldn't even be aware of necessarily.

(43:24):
How interesting. Just the level of nuance for depending on how close you are to the problem.
When you're thinking about building in public and being able to get feedback from the users and
engaging with people and kind of having the code, the issues that you're working on day to day be
so visible, did that take any getting used to? Is there an adjustment period?
It is. It was. And it's very interesting still. Now that where I would join GitLab before we were

(43:51):
publicly traded, and that's affected what we can share. And there's legal reasons for that. And so
I'm like, no problem with that. It's part of the deal. The really interesting thing is something
I would, the main way I would sort of characterize it is what I was sharing before about you do a
asynchronous issue update on the thing you're working on. And anyone in the world can see that

(44:13):
for the most part. Like I said, we have security processes where we're not going to release that
till we have fixed. And nor should we, I don't think. What's very interesting about that is
because the whole team is using that issue to communicate, the customers are looking at it.
So if that's what we call a GitLab, a single source of truth. And so that's the thing we're
working on. And that means that anyone can engage in that. So I've interviewed people who have watched

(44:38):
my team meetings, because we used to publish team meetings on YouTube on GitLab, unfiltered.
They've watched our team meetings, they see how we interact. And then they come into an interview,
they've applied for a role and they're like, yeah, oh yeah, I watched the team meeting. And I looked
at this issue you're working on. And you were like, ah, sweet, that's awesome. What did you think?
You know, like, that's great. So this idea of having a public single source of truth,

(44:59):
there's a lot of issues that come up, like I mentioned before, when we're making contentious
decisions and talking about it, we haven't even made the decision yet. You've got people coming in
and sort of treating it like it's a normal org that's going, we've already decided when we have
it, we're just talking about it. But you see us talking about it. And so what's interesting is that
you have one version of what you communicate. And I think that's one of the things I've loved about

(45:21):
working at GitLab is like, we don't have the internal version and the thing we tell our
customers, because the customers can all see the thing that we're doing. There's no kind of having
the split brain when you go, I've got to talk to a customer, so we're only going to say this.
Now, I'm not trying to characterize other organizations as being disingenuous or anything
like that. It's a pretty normal way of operating. You see it inside organizations as well,

(45:44):
where certain teams know certain things and it's not disseminated, it's need to know,
all that sort of stuff. So that's a very big difference to the way GitLab has always worked.
And super interesting, like when you think about it and just go, huh, I've got the work I'm doing.
And if a customer is like, hey, what's up with this thing? You go, here's the issue. And the
customer is like, hey, can we do this instead? And you're like, that's a great idea. It's awesome.

(46:04):
How fascinating. What a nice way to, what a good benefit to have of that structure.
Thinking about hiring and being hired, would you walk us through your philosophy on hiring for
your team? Yeah. I mean, like I said earlier about processes, it sort of depends on the needs of the

(46:25):
business, right? You know, like in general, you're looking to fill a need. The role we have open
right now is specific around a particular need that our team has. And so we have a hiring process
that's best, how do I phrase this? Some organizations like to get everyone or a representative of
everyone who's going to interact with this potential team member and have them interview

(46:46):
and get their opinion on it. And some organizations like GitLab, we do behavioral interviews,
but we generally do one person to one on one. And that person is responsible for assessing
that candidate at that type of thing. And so the way you could look at that is like,
we do a hiring manager interview, and that's generally going to focus on values,

(47:07):
values alignment, how that person will engage with the values at GitLab, but also team members.
Then you'll have technical interviews. And the technical interview is purely, not purely,
but mostly focused on how that person communicates, how they work technically, what the take home,
if they have a take home is like the technical evaluation of their capability. Then you'll have
on a product team, you'll have a product manager interview where they're actually assessing that

(47:32):
person's ability to engage with the process we have. So it's more about the different capabilities
than it is about individuals saying, yes, I want to work with this person or not.
GitLab, and I think this is a good approach here is we think about a values fit and a culture ad
and so that's a way to think about hiring a team that has different perspectives,
allows you to better understand and represent what your customers who are all different

(47:57):
are going to want out of a product. And so that's where I think diversity comes into hiring.
It's actually really a big business value. Now, I can certainly see the argument if you're like
three person startup and you've got one idea and you want to get that done, if you had clones of
a single individual, maybe it would go quicker because you wouldn't argue about anything and
that's the thing you're doing. My favorite place to work, I don't know, work with me.

(48:19):
That would be weird. Might be a lot.
Definitely. I'd get annoyed with myself real fast, I think.
But like, so that's why it's so important. Like, so when you're really hiring someone,
you're hiring people with the intent of being able to better understand customers without always
asking customers what they need. I mean, in general, just intrinsically in the way that we work,

(48:43):
it also allows you to hire folks with different strengths and enable those people in those
strengths in the role that they have and help them be impactful in the role that they have
commensurately with the level they get hired at. And so when you say values fit culture add,
that's what that means to me. Cool. Love that. Very educational. Thank you.
When you were thinking about your team specifically and the nuance that you would be looking for,

(49:08):
what is that? What do you look for in the people that you hire?
Generally, I'm trying to find, it's not the best phrasing, but I haven't come up with a better one.
So I apologize in advance, but I kind of think of the through line for the team.
And this doesn't change values fit culture add. But how does the team interact? How would you

(49:30):
describe the sort of the feeling of working in this team? A lot of the teams at GitLab,
because it's one of our values, are very collaborative, they're very supportive.
And so when you interview someone who's very much like, "I just like to go do it myself and then
come back." Maybe there's a need for that in the team. Maybe there's a bunch of projects that are
outstanding where you just need someone to really go hammer it out. But the question mark comes up

(49:54):
of whether that person is able to communicate effectively with other folks. And so that's maybe
where you focus during the interview process. But that through line is the idea of how would you
summarize working with this team for a week? Everyone was super helpful whenever I needed
something. They were like, "Hey, what do you need? I'm going to drop what I'm doing." Other ones were
like, "Hey, here's where the runbook is for dealing with that issue. So go check it out. Let me know if

(50:16):
you have questions." That's kind of a different feeling for a team. So really in hiring, what I'm
looking for is that. Values fit, culture add, and then someone that could actually integrate well
with the team. Not that they communicate the same way, not that they talk the same way or any of that.
But maybe they just love to write things out more than they want to talk in a meeting.

(50:37):
That's cool. They're still communicating. No problem. It's not an issue.
So I think that's how I think about hiring. It's like having someone that can add something to our
team, not just in the work they produce, but the way they interact with other folks in the team.
But also, it isn't going to be super disruptive to the way the team can move forward.

(50:57):
Disruptive is a very subjective thing to say, and I acknowledge that. But that's in service of the
team being effective, not in service of me and what I think is the right... I'm just one member
of the team in the context of hiring. Interesting. That makes a ton of sense.
If you were to give some advice to your younger self or anyone in the audience who's listening,

(51:19):
who's aspiring to a similar path, what would you share and what would you do differently?
I've very much taken jobs that I was like, "Oh, that seems fun." Like my whole career.
Such a random set of jobs in technology. I ended up getting into it because I ended up doing computer
jobs to support myself when I was in university. So I was like, "I'm working in an Apple store,

(51:43):
and I'm working in this shop, and I'm doing this." And it just like, "I should just start
working on computers. This is pretty fun." So that's why I ended up there. Then I've been
working somewhere and I get a bit bored. Then I'm like, "Oh, that sounds like fun. I'm going to do
that now." And pre-sales tech, IT manager, support engineer, developer, whatever. That leads to a
point in your career where I'm not a spring chicken anymore. I'm like, "I really want to go somewhere

(52:10):
in my career." If I'd started with that focus earlier on, I might've got there sooner and I
would have missed out on a lot of really interesting opportunities. So I think even when I retrospect,
I'm like, "I wish I'd focused a bit more." But at the same time, I'm like, "Yeah, but I did so much
different stuff." It's super interesting to be able to be like, "Yeah, I built software from

(52:33):
scratch for a law firm and I was the only tech engineer in that team and everyone else didn't
like us because we're doing weird stuff." So it's not so much I'd do it differently, but maybe
consciously acknowledging that. If you're really keen to be in a specific role, then go for it.
Like try not to get too sidetracked, but recognize if you do get sidetracked by something that seems

(52:56):
fun, then you're probably going to learn a bunch from that process as well.
ASH BENNINGTON Sounds like the value of following the path of least resistance,
sampling from the buffet of what might be available. And then once you start to be able to
recognize that good fit, what is appropriate for you, where you want to be, then lean in.
JONATHAN B

(53:33):
about what you might want to share with anybody who's interested in getting into the world of
open core or open source software development or productivity, what would you share with the people
who are on their way up?
JONATHAN B Yeah, productivity itself is an interesting space. As far as I've been able
to gather, there's not a lot of consensus of we use the space framework for assessing productivity

(53:58):
or we use Dora for metrics or whatever. I think that probably just comes from how different
businesses think about productivity. Some businesses are very much like its velocity and that's it.
And so maybe some different measures work and other companies are like,
"Oh, well, how do people feel about it though?" question mark.
GitLab was historically MR rate, which was an average number of MRs per team member per

(54:21):
month or whatever time period, which is a quite opinionated thing to say. And we don't really do
that as much anymore because there's lots of side effects. So when you're getting into productivity,
if it's something you're really interested in, you're really trying to solve the needs of a team.
And I think one of the things that can be tough is you can get people saying, "This is what's

(54:42):
bothering me," but it doesn't necessarily represent everyone's experience. So you got to figure out
how best to help in general. Where's the best place to start? As far as getting into open core,
open source, it's all out there. That's the coolest thing about it. If you're really hyped
on it and you're working in some of the job right now, go look at it. If you don't have the energy
to work on it after hours and you're not stoked to go contribute some simple fix to some project

(55:07):
that you're interested in, maybe think about whether you have the energy. Lots of folks
are in a position where they're working and they go to school. And so I'm not suggesting that type
of energy. I'm more suggesting that idea of, "Do you feel motivated to actually go do the thing?"
Even in spite of working on something else. And if you do, you totally can. I mean, it's easy for

(55:27):
a single mum who's trying to do three jobs at once. I appreciate that. So that's what I would say
for folks maybe pretty early on or folks that are working in non-open source. If there's a project
you use, if there's a project you're interested in, you can always contribute. You can go read the
issues. You can go look at the code. You can learn from it. And that's one of the coolest things
about it. Yeah. I love it. To avoid the buffet, you can sample from the tasting menu. Right?

(55:52):
Go try a bunch of different things. You can get delivery and then you can see if you like the
restaurant, you can make a note about which ones you like and which ones you don't like. And if you
don't find you like anyone else's cooking, then maybe it's not for you. Question mark. I don't know.
There we go. There we go. I dig it right on. So what are you excited about for the future?

(56:12):
We have an eight month old. That's top of my list. Nothing else comes close as far as I'm concerned.
She's the best. Work-wise, I think it's pretty interesting. I read one of the YouTubers, I forget
their name right now. I could look it up later. But there's a video they put out last week,

(56:35):
sometime talking about how they're studying these studies and the way that AI and code
suggestions are being used in work. And they're finding there's a lot more churn,
code churn, meaning that code is written and then changed again and then changed again.
And so they're finding there's a lot more code churn, at least the way the studies had kind of
come out. Some of the sources of this particular study the person was sharing were, didn't seem

(56:58):
that great. There seems a little bit kind of not really statistically significant or whatever. But
that idea, it feels like it could be a little bit of confirmation bias in the sense that we're
worried about AI and how it affects people's work and jobs. And that's not just software engineering.
We've seen that come up in acting in the US and voice actors and script writers and all sorts of

(57:21):
different occupations. But specifically in software engineering, I think it's a really super
interesting space. And that consideration around seeing how it actually plays out,
lines up a lot more with at least how I've been thinking about it and other folks have been
thinking about it, which is like, this is a tool for humans. It's not putting everyone out of a job.

(57:43):
If it is putting everyone out of job, that's scary, obviously. And I know why people are concerned
and I appreciate that. But I think what I'm excited about on that front is actually making those two
tools work well for everyone. GitLab has code suggestions as part of our product. We released
it just at the end of last year. Plug, plug, plug. Sorry, I mentioned Copilot because this
particular one knows about it. I've got to mention GitLab here.

(58:04):
Understood.
But lots of companies are coming out with these tools and what's the actual medium to long term
effect of that? I think there's a whole other opportunity in there for people to really level
up and be able to produce. We talk about, and I don't really like the terminology, but we talk about
10x engineers in the context of writing code. Having AI and code suggestions tools is supposed

(58:29):
to help everyone be 10x. Does that mean our 10x person isn't just a 10x still? Or does that mean
they're 100x? Question mark. So this is this idea of refining these tools and making them actually
work for human beings and businesses in a way that's actually good. Because a lot of times,
the accepted interest rates are pretty low and people are like, "Oh, this is terrible. I want to
write it myself." In the context of the future, nobody knows what happens next. And when you're

(58:52):
thinking about open source or open core software in 2030 and you had to make a bet, where would you
put your money? What would you think about? I think this sort of inflection point with AI,
and I know that chat GPT and those folks have been talking about having a general AI and stuff
like that, and people are pretty worried about it. I think that's one of the biggest question marks

(59:15):
everyone has now and for the moment. Governments are starting to legislate. We're starting to get
a lot of legal cases about artwork being copied and not being attributed and folks who are
actually producing the art that's training these models and not being compensated for anything.
These are untested for the most part in the legal setting. Government regulation is not

(59:39):
going to necessarily stop things. If it's just one country, it is always accessible. You've got
various countries restricting. I know that I think it was Italy a friend of mine was telling me that
has rules against there's a pizza ordering site, but because it's AI, they're not allowed to use
it. It's like illegal now or something like that, which is hilarious. But I think that to me is a
really interesting space to be in right now. And I think that could yield depending on where we

(01:00:03):
settle out as far as legal cases and legislation from government control, it could actually yield
a result where we sort of separate any AI generated code into separate kinds of things and say, okay,
this is separate. But for a lot of companies, I think this is going to be an opportunity.
This is going to be an opportunity for people to generate projects and products that they wouldn't

(01:00:24):
have been able to before. And the risk there is like what we see a lot on YouTube and those
types of environments where there's just AI generated videos that just rip people off. And
like it's actually a legit problem and the business YouTube can't figure it out. Like it's
a hard problem. I'm not throwing shade at YouTube, but it's a really hard problem.
You get that sense when you look at it of like, this is dodgy. I'm not going to watch this video.

(01:00:48):
This is totally a rip off and I'm not going to watch it. Do we have that sense about code? Have
we adapted to the point where we kind of go, this seems a bit suspect. I think open source software
provides us the best opportunity to identify that in the products and services that we consume.
So to do a bit of a plug for Gear Lab again, I think that is a distinction.

(01:01:11):
As we bring this to a close, are there any reflections or thoughts, ideas or inspiration
that you'd like to share with the folks listening out there?
Yeah, they'll span a bit. I love Turn the Ship Around by David Marquette. I think it's an
awesome book on sort of approaching leading humans and what that looks like. There are YouTube videos

(01:01:31):
that do the 10 minute breakdown of what it is. I think it's worth reading the book, but for folks
that don't want to do that, go check it out. Daniel Pink's Drive is another one of those that
I think is awesome. I know there've been subsequent releases and I haven't looked at as much of that.
Self compassion. Like you got to love yourself. This is hard enough. Peopling without our own

(01:01:53):
inner voice, making us feel bad about everything we do. The people around you care about you.
It's hard right now, especially with a lot of layoffs and all of this stuff going on. So
mental health is tough. It's tough for everyone, let alone if you've been through layoffs and all
of that kind of thing. I think just find something you can be stoked about. Gear Lab's been the best

(01:02:16):
job I've ever had. I might say differently in two years time. I might say the same thing, who knows?
But it's been so fun. But I think that's the big thing for me. I want to say really quickly,
and I'm deep diving a little bit here. But when you find your inner voice beating you up,
ask yourself how you would talk to your best friend or someone you love in the same exact

(01:02:39):
situation. That is to say, "Oh, I've done something." Put your best friend or someone you love in the
same situation. No qualifying. Don't be like, "Oh, yeah, but no." What would you say to them?
Then evaluate how you talk to yourself about the same situation. I think a lot of folks would find
that they would never say anything approaching to others what they say to themselves in their head.

(01:03:01):
So their inner monologue, I think, is rough.
Beautiful. That's wonderful. Is there anything else that we skimmed over that we perhaps didn't
cover that you'd like to talk about? No, I think we're good. I'm pretty happy.
Did you think we skimmed over anything, Ryan? Dan, thank you so very much for coming on the show.
This was such a delight. I learned so much. Thank you.

(01:03:21):
Yeah. Thanks, Ryan, for your time. It's been nice to chat with you. It's been fun kind of reminiscing
over some of this stuff and feeling awkward the whole time. But I generally feel awkward,
so that's cool. You did great. Cheers. Thank you so much. Thanks.
Our next episode is with Aaron Pryor, Chief Marketing and Experience Officer of First
Horizon Bank. I really, truly believe in surrounding myself with people smarter than me

(01:03:46):
and challenging one another. If you enjoyed this episode, make sure to subscribe for new episodes,
leave a review, and tell a friend. Good Fit Careers is hosted by me,
Ryan Dickerson, and is produced and edited by Melo-Vox Productions. Marketing is by Storyangled and our theme music is by Surf Tronica with additional music from Andrew Espronceda.

(01:04:07):
I'd like to express my gratitude to all of our guests for sharing their time,
stories, and perspectives with us. And finally, thank you to all of our listeners.
If you have any recommendations on future guests, questions, or comments,
please send us an email at [e-mail].