Building a Unicorn Engineering Org at GRIN

**Brent Bartlett** (0:00)
We're in a space that we're providing a tool and a system that is only valuable to our customers if it can demonstrate its own results. And by the way, it does.

**SPEAKER_2** (0:12)
This episode is sponsored by LinearB.
Accelerate your development pipeline with data-driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at linearb.io, and mention the Dev Interrupted Podcast discount for one month free when you sign up for an annual Pro membership.

**Dan Lines** (0:33)
Hey everyone, welcome to Dev Interrupted. I'm your host, Dan Lines, and today I'm joined by Brent Bartlett, the VP of Engineering at Grin. Brent, thanks for joining us, and congrats on the recent $110 million series B round.

**Brent Bartlett** (0:49)
No, thanks a lot, Dan. Super glad to be here, and looking forward to the conversation.

**Dan Lines** (0:54)
Awesome to have you here.
Now let's start with giving our audience the opportunity to get to know you a little bit better before we dive into Grin. I know you joined Grin as Head of Engineering. It was around December 2019 It would be really cool to hear your career journey. How did you get into such a great role with Grin? What did you do before that? How did that all happen?

**Brent Bartlett** (1:20)
It's interesting. It's been like fast and slow at the same time. It's one of those things where when you're starting your career, it takes a long time and sometimes the pacing isn't what you would expect. So I started as an engineer at Hewlett Packard way back in the days prior to the.com bus. That was like my first entry into the market. And then during my journey, I've worked with some of the largest companies on the tech side and some of the smallest, I will say, like little small startups. Recently, before joining Grin, I was director of engineering at Schilling Robotics, which is a deep sea robotic company.
So they make robots about the size of a minivan, they go down to the bottom of the ocean. And that's been some of the companies I've worked with before joining Grin.

**Dan Lines** (2:01)
The Schilling Robotics sounds pretty cool. What did you learn there that sounds really interesting?

**Brent Bartlett** (2:08)
It was definitely interesting, man. It's a harsh environment from just the product side, out in the middle of the ocean on a boat with no other support around you. These boats go out in the middle of the ocean, they sail for like weeks to get to where they're going and then drop robots off the side and they go down the bottom of the ocean. So that brings all sorts of challenges. When I was an engineer there, I was thinking about all of the different unexpected events that could occur where you're working at your desk typing code and then one day you might be flown off to the ocean. So it's dynamic.

**Dan Lines** (2:42)
That's awesome. Is there anything in your career journey, you're a software engineer, you got a director role at this interesting robotics company, then you come to Grin, what kind of jumpstarted your career to even get onto this management track?

**Brent Bartlett** (2:59)
I'm not sure if there's a particular catalyst of an event. I think that leadership is a journey, right? Just like the career is a journey.
And one of the things that I really enjoyed about engineering is problem solving.
And probably about, I don't know, I don't wanna age myself too much here, but I've been doing software leadership for quite a while. And you start getting to the point where the technical problems, you understand how they work. Like engineering's really hard. It's very challenging. And you know when you're done, you know when your problem works, when your code is executing and performing what you want it to be. So those problems get into a mode where it's really prescriptive in a different way than when you're doing management and leadership. When you're doing management and leadership, it's still problem solving.
And the problems have all sorts of unintended side effects, consequences and definition is challenging of what the end state is. Right, like how do you know that your employee is performing well? Are they performing their best? How do you know that they're performing their best? How do you know that you're performing your best as a software engineer? Am I performing my best? Could I be doing better? Can I be more efficient, more productive? Those are the thoughts that I think start catalyzing in future software leaders' heads when they're typing code, when they're being an engineer, when they're solving hard problems, when they're evaluating code reviewing, their peers work. So those things are probably like early signals that maybe formulated in my head is how do I make myself more just able to be as good as I could as an engineer?