How do you build an engineering organization that can drive your company to a billion-dollar valuation and unicorn status?
And how do you do it in an emerging and highly-competitive product category like influencer/creator management? Brent Bartlett, VP of Engineering at GRIN, joins the podcast this week to share his blueprint for success and his path to leadership.
Listen as Brent shares his advice on how to use intuition to inform data-based decision making, how he managed GRIN's engineering department during it's explosive growth on the path to a billion dollar valuation, and why he trusts LinearB to help him succeed.
Episode Highlights Include:
- Building an engineering org in a highly competitive product market
- How to blend intuition and data when decision making
- Why GRIN chose to partner with LinearB
- Institutionalizing knowledge and communication practices while scaling
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Transcription:
Building a Unicorn Engineering Org at GRIN
SAT, 20 NOV 2021 03:00:00 -0800 ◦ 40 MINUTES
---
Dan Lines: Host
Brent Bartlett: VP of Engineering at GRIN
---
[Music plays]
Brent: [0:00] We're in a space that we're providing a tool in a system that is only valuable to our customers if it can demonstrate its own results, and by the way it does.
Producer: [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: [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: [0:49] Oh, thanks a lot Dan. Super glad to be here, and looking forward to the conversation.
Dan: [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: [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 dot com bust. 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, they are about the size of minivan, to go down to the bottom of the ocean. And that's been some of the companies I've worked with before joining GRIN.
Dan: [2:01] The Schilling robotics sounds pretty cool. What did you learn there? That sounds really interesting.
Brent: [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 to 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 good dynamic.
Dan: [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 jumps started your career to even get on to this management track?
Brent: [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, it's-I don't want to age myself too much here, but I've been doing in software leadership for quite a while, and you start getting to the point where the technical problems, you understand how they work. Like engineering is 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 leadership, it's still problem solving, and the problem 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 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 formulate in my head is, how do I make myself more just able to be as good as I could as an engineer? And then those optimization techniques led me to solving problems in that space that then provided larger impact when maybe going into a team league and then into a manager and so then into a manager, managers into a director and to VP it's just a journey. I don't know that there's any particular inflection point that I can point to though.
Dan: [5:01] Yeah, it sounds like you started having the right thought processes. Okay, so how am I improving myself? Or what does it mean to be a great engineer? What does it mean to lead a team of engineers? What does it mean for them to be great software engineers and then to deliver? Yeah, it seems like it maybe was a little bit more progressive for you, but you started having those thoughts that probably got you more so on that management track, as opposed to maybe, “Hey, I just want to be a principal engineer, and that's my journey”.
Brent: [5:29] I would say so I think it's really-yeah, it's about problem solving. And I think the problems that I was solving as a principal engineer and architect, and I've served in those roles, they weren't as-as compelling to me as some of the problems that I was solving, when I would consult and help a colleague, get over some type of troubleshooting methodology that they didn't quite get. So they might have been really good at writing the code, but maybe they couldn't diagnose it, and so then I would teach and coach them. This is like an individual contributor level, right? Like, here's some things that I do to tackle this type of problem that people would come to me because they like, I'd get a reputation for being able to solve those types of things. And I found that very rewarding and then started exploring, oh, there's a role for that.
Dan: [6:16] Very cool. Now GRIN is obviously a “rocket ship” company, huge Series B round, I know that your engineering team is scaling, you're in this great position, leading the engineering organization, how did that opportunity even become available for you to join GRIN? Did you join early on? Did you have to take a risk? I think a lot of our listeners would love to be in your position. So how did that even come about to even join GRIN?
Brent: [6:44] Yeah, so I would say that, as most opportunities are obvious in hindsight, they often are not obvious when presented to you. And so this is something I would encourage people to reflect on is that usually when people evaluate the position that someone else has, and some-something that like, they might have these thoughts of, oh, this individual always gets all these opportunities handed to them. That's something that people tended to think and internalize. Rarely is it so gold platter presented, such that the individual would think that at the time it was presented to them. So when I was evaluating different opportunities, I saw GRIN and I saw it as an opportunity. If I were younger, I might not see that same situation. It was very early at-prior to the massive hypergrowth of GRIN. And so I was coming from a team where I had a large software organization that I was managing, and I remember talking to the recruiter about the opportunity at GRIN, and they're telling me “Yeah, you'd be in charge of leading the engineering department really building it, scaling it, defining it, and growing it.” and I’m like “Wow, that sounds great.” and he's like, “Yeah!’ and so I asked, “Could you describe the engineering department?” and he’s like, “Yeah, it's three engineers.” And I was like, “Okay, cool. What else?” and he said “No that’s it, that’s the department.”.
Dan: [8:06] That’s it! [laughing]
Brent: [8:07] That's it, and I was like, “You don't need to hire me, honestly. You should go hire an engineering lead or something else. Like, I'm not the right person for this position.”. And after talking to them, and really understanding what GRIN was, and where we're going, I immediately swallowed the Kool-Aid and understood why they're looking for a VP role for a team of three people. And yeah, I was sold and immediately joined. But someone else might look at that and say, like, “this isn't a position I should be taking.” and it rarely-like I said, it rarely is, the opportunities often are presented to multiple people. And it's the person that sees that, hey, there's a problem here, this isn't good. Usually opportunities aren't in a perfect, ideal, good presentation because they’re rarer, right? It's like you end up taking something that is a problem and a challenge and then finding the joy of nurturing it and growing it and making it as good as it can be. And then at the end, you have this great situation that others are envious of, that they would never have taken at the onset.
Dan: [9:12] One thing that it reminds me of, we've had a lot of successful people on the pod, a lot of engineering leaders, and it just brought up for me, sometimes it may appear that you need to take a step backwards in your career in order to go 100x further. So like the example with you, I think you were leading probably a much bigger team at the robotics company, and maybe if someone came to you and said, you know, “Hey, Brent, do you want to take on the role leading three engineers?” you might say to yourself, “Oh, that sounds like-a I don't know a team leader position or it seems like I'm going backwards.” No, you were able to see, probably from the founders, something much greater than that, and now look where you are, like probably much further ahead in your career than maybe you would have ever imagined.
Brent: [9:58] Definitely having that perspective is healthy of releasing your ego. I'm at a stage where my intent is to evaluate how I can help my organization, how I can help the team, how I can help the company, and that needs to be done in various ways. There's things that that I do which someone-I don't know, it's like you being allergic to “that's not my job”, or “that's below me” is something that's really important, I think, for just professional and personal development in general.
Dan: [10:29] Absolutely. Thanks for, in the intro part here, taking a little time for everyone to understand your career journey, and how you got to a point of leading this incredible engineering team at GRIN. I do want to make sure, now, that we take some time to dig into GRIN as well as it's a super interesting company that you've grown here. Can you tell our listeners a little bit about GRIN and what you all do?
Brent: [10:53] Yeah, for sure. First off, I just want to say that I couldn't be more proud of the engineering team that is at GRIN, my staff and my team is incredible. I'm super humbled every moment I talk to the engineering team and see what they're able to achieve. It's totally incredible, and it I'm sure you can appreciate this, Dan, you look at this and be like, “Man, I don't know that I would be able to-to keep pace with these people if I were working in their shoes” I'm super privileged to have them on my team. So GRIN as a general company is incredible. I really do like it, the founders are top notch, and it really comes back to the right market timing combined with the right product. So our product is a SaaS application for creator management. And so what that really is about is all of the interactions that someone might have if they were trying to sell a product online to a consumer, and they wanted to get someone from social media to talk about their product. So that's what GRIN is from a product perspective, and we really believe that comes and works best through an authentic relationship with content creators. So no middlemen, you're not like going to some Craigslist style job board and posting, “Hey, if you post on Instagram about my product, I'll pay you five bucks” or whatever, that doesn't really get the right result. I think we've all seen those kinds of awkward placements in our streams and our social media feeds, And it's just totally, like, obvious, and it’s-
Dan: [12:27] Weird. It’s weird. It doesn’t fit, [crosstalk] [12:29] something’s wrong here.
Brent: [12:29] Exactly! Exactly, and so authenticity is exactly the opposite of weird. When you see something from a trusted source, or hey, I really like Linus tech tips or something, and then you see something that he's recommending, it's like it's natural, because you know that he's an authority in that space, and this is something that he likes and is showcasing, and it has a completely opposite effect. It's genuine, it's authentic. It's a trusted source, and it's very powerful. And so our product is allowing the customers of it, like our brands, to have systems and tools to help them build those authentic relationships. That's what the product is about.
Dan: [13:08] The product is usually the company and vice versa. Now for the users of GRIN, is it both the influencers and companies that want the influencers to do a thing? Or is it one side or the other? Like, [crosstalk] [13:20] who’s using it?
Brent: [13:20] It's really one side. So you can think of it like Salesforce, it's a product that's used by the-the marketing teams of a company that-that has, like, our customer’s primarily focused on direct-to-consumer brands that would like to do influencer marketing or other activities. And so it's a set of capabilities that assist them in that, it doesn't manage it for them.
Dan: [13:44] Gotcha. Now, this is such a emergent space, and this is the way I think a lot of companies want to do marketing now. And I assume that you're needing to move fast, and probably a lot of demands on engineering. How do you go about building the product? Maybe with all of, I don't want to put words in your mouth, but maybe pressure to move fast or innovate? What is your product methodology at GRIN?
Brent: [14:13] Yeah, that's always the case, right? Well maybe not always, I would say in an emerging market, it's always the case that it's all about moving fast, it's all about being first, and at GRIN, it's no different. It's really important to optimize the customer value that's going and moving through the engineering team. That's a very critical part of any engineering organization that’s successful, is being able to seamlessly flow the results and the output of the product team and the strategic roadmap into customer hands. So it's definitely part of our strategy, it's definitely high pressure. How do you manage it, is that's the role right? That's the job and so really, anything that I can do to help identify what bottlenecks are, what things would accelerate us, so focusing on accelerants and friction, and removing the friction and adding more acceleration and just like, pretty-pretty basic equation. So I can give you an example of friction, so like friction could be the types of challenges that you-you have when you have that synchronous communication required between teams. So you have one team working on a particular module and another team working on a different module, and there's an interaction between those and something about that interaction needs to change because of some kind of feature capability. And so then the team needs to communicate with the other team, now you have this synchronous connection, which causes friction to the results. So is there a way that you can build within your team in your organization asynchronous methods of communicating such that there isn't that friction so that things and-things still happen with the right result, without that interaction, that then slows down the work itself, that would be a friction base. Now, an accelerant would be some-there's a lot of different ways, but at an organizational level, you might have some type of process, that's your standard, but you don't have it really flushed out and communicated and institutionalized throughout your work. And so if you can do that, institutionalize it, now you can have a baseline through which every team is performing some activity, right? Like, it doesn't matter what it is, you just take anything, let's say code reviews, right, you have some type of standard for how code reviews are conducted. Now, that's a baseline, that's what standard means. I know a lot of engineers hear the word standard, and probably the hairs in the back of their neck or are standing up right now as I'm talking. But the idea of a standard is that it provides a baseline expectation through which now everyone can do experiments to improve. And if they can find some method of improving that standard, improving how you're doing code reviews, that makes it faster for them, you can update the standard across the organization provided-or that institutionalized capability of how to do this, and now you've raised up and accelerated across the team.
Dan: [17:10] Yeah, with-in terms of the standards, I think about it as here's the floor of how fast we're gonna move.
Brent: [17:17] Exactly!
Dan: [17:18] It doesn't mean that you can't innovate and say, “Hey, you know what, we're gonna notify each other about PRs through slack” or whatever it is that you decide you're going to do to innovate upon the process, but it's more just the floor. That’s where-[crosstalk] [17:32] that’s the starting point, yeah.
Brent: [17:32] The baseline, that's what standard is. It's the baseline, floor expectation. And that's why we-what do we do with standards, right? You always raise them.
Dan: [17:41] Is there any tips or something that you use as a leader to find where you need a standard? Or, “Hey, I know that these two modules are going to have a friction point.” Because sometimes, as an engineering leader, especially as your team is growing, it can be hard to say, where can I make an impact? Like where should I-do you have anything that you use like, a spider sense to figure out where you should be?
Brent: [18:07] I know where you're going with this, because there's a lot of ways of doing it, but you got to have data man, like Spidey senses can help and intuition is great, and generally those are-the Spidey senses or intuition should lead you back to some level of data, if you're talking at the organizational level. If you're really at the edge, or like individual contributor level, as an engineer, your intuition can help you rapidly solve an issue or-or create a code solution. That's great, that happens all the time. However, at an organizational level, when you're dealing with a lot of different people, it comes back to data. And so having information available to you that you can see that there's something that's being measured, that's just instinctually taking too long, or there's a Delta on a particular team and so there's a lot of disparity between how long certain things are taking for different teams, that could be a signal that you really need to dive in and look like. Like, there's a lot of different ways of seeing that, but one is just variants, right? Like one team does, like the similar types of activities at a much different rate than other teams, whether it be longer or slower. So if it's very slow, you might want to dig in and figure out like, what's going on here? Is it the type of work, is it the processes, or something they're doing novel? Or if there's an outlier that's going way faster, It's, “Oh, man, how do we make that the new standard?” right? So I would say having information and data so that you can see disparity, you can see different things that are happening on your org, and in your team can really point out some places where you have either-or like friction opportunities or accelerant opportunities.
Dan: [19:42] Yeah, absolutely. First and foremost, we are super proud to have you and GRIN as LinearB customers. And so of course, I know that you have some of this data at your fingertips that you can see where maybe I have a bottleneck in my delivery pipeline or like you said, “Hey, which team-maybe this seems operating a little bit differently, and I can go and help them”. Let's just jump to that topic now. Why did GRIN decide to work with Linear B?
Brent: [20:11] So GRIN is a very data centric company, we're in this 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. So anyone listening that needs something, a solution like this, they should be looking into GRIN or other solutions like it. But the bottom line is at GRIN, we use a system called EOS. Are you familiar with that Dan, [crosstalk] [20:40] Entrepreneur Operating System?
Dan: [20:40] EOS? Yeah.
Brent: [20:42] And so the Entrepreneur Operating System, it's a way of running the entire company, not just the engineering team. And there's a lot of aspects to it, and one in particular, getting hyper into the EOS lane, is the concept of a weekly scorecard. And so on your weekly scorecard every team in the entire company, and every individual at the entire company has a number. That's like the statement, every person at GRIN has a number, and that's a metric. And so it's really hard to find good meaningful metrics at an individual level that are helpful and not distracting or harmful to an engineering team, and it's really hard in general to measure. And so what I wanted, and I've always wanted in my engineering orgs, are what I call “free metrics”. So these are pieces of data that I don't have the large organizational cost to attain, meaning I don't have to have analysts or other people spend a lot of time and effort curating this information. And we have so much data that's happening just as part of the work that we do, that I explored for systems that could create some of this data or showcase some of it and LinearB really stood out for me as the system of choice in this space. And so having it connect up to our systems, and then just provide vast amounts of data in a very clear way that I can explore and see without having my team members spend a lot of time curating it, or changing processes, putting various flags or fields on tickets every time you do something so that it can make sure that it-the metrics can pick it up, all of that was something I was looking for.
Dan: [22:26] Yeah, gathering data takes time, that's the truth. Like, before I founded Linear B, at my previous role, I was a VP of engineering, I had a team then started to get up to four or five people that were just, like, gathering data. So that we can see [crosstalk] [22:40] where do you- where should we spend time? How do we help our engineers in the best way possible?
Brent: [22:40] Get analytics yeah.
Dan: [22:45] That's crazy! That's four or five salaries, and that's a lot of time. You know, one thing that was interesting, you have some of this data now from Linear B, do you use it with your executives? Or do you use it just with your team?
Brent: [22:58] I'll say yes for the programmer answer when you put the “or”
in there. I use it for executives and the team, yeah, for sure.
Dan: [23:04] The executives-like, can your CEO understand it? Or how do you [crosstalk] [23:08] pitch it to them?
Brent: [23:08] Yeah, I mean, they can for sure, there's different pieces of data that I use at different levels. So when I aggregate up the data for, say, the entire engineering department, one of the areas that I really like is looking at-and so this for the executive level that I present out, is new code versus rework. So how much new code-what's the percentage of software that the org has written that's new, and how much of it has been written within the last three weeks and then had to be rewritten or reworked because it was whatever? There's a lot of different signals that can tell you right, like maybe it was improper requirements, maybe it was written too hastily and there's defects. There's a lot of different signals that rework can tell you, but that's one that I think people understand the value of having higher amounts of new work and low amounts of rework.
Dan: [23:59] Yeah, that's probably one of the most popular metrics, especially the situation that you're in is, you probably care a lot about speed when you're in the emergent space. Where's the friction? Can we-you said that best I think, can we move value from idea to get it into the hands of the customer? Rework’s an area that's going to show you “Okay, we have some kind of pain point happening here, let me dig in”. One of the things that we've been probably innovating the most at Linear B is our WorkerB functionality. So we kind of realized, okay, it's great for CTOs, VPs, you got to have this data, you can talk about it with your team members, your CEO, make decisions, you know, dive into bottlenecks in the pipeline. But what WorkerB’s really doing is actually helping teams move faster with their PR, is higher quality, it's also for individual developers. How's WorkerB been treating you?
Brent: [24:52] Yeah, we have some people that use that for sure, and I think one of the big positive points around systems like LinearB and in particular, I think the core metric that we use it within the team and-like we use at the individual level, but it's not used for any other reason just to like-for awareness of each individual can evaluate it and see his cycle time. That's like a big push, the lower the cycle time, the healthier your organization, that's just-it tells me so much. So a challenge with a metric like cycle time, is that it's got so many dependencies throughout your engineering team and it's very easy to externalize the rationale of why it's bad. So if I'm an individual, and I'm saying like, “I'm going to deflect responsibility for this”, which is totally against GRIN core values but you might do it unintentionally, of our DevOps pipeline is just janky today, and this week has been really bad and things aren’t doing well, so the fact that my cycle time’s bad, this team over here that's doing something, or the DevOps team might be like, it's really like test automation going on like that because that team's got some challenges or whatever. When you break it down into its composable elements, and you get to like review time, that's something that is 100% in your control, right? If you're assigned a PR to recode-review, how long you spend, how long you take, what's your pickup time for it, that's on you, you don't have the luxury of externalizing rationale of why it's not good. And so WorkerB’s been really helpful for that of just helping notify people of those types of triggers and events.
Dan: [26:30] Cycle Time is one of those leading kind of health indicators of how efficient are we able to get work done. But like you said, there's so many different components, people working together, teamwork needed, it's not just an individual contributor can go end to end, if you're just a developer, you can't just get-actually get all your work done and get it out to production. So a lot of what WorkerB is doing is that coordination, hey, you have a PR, someone's waiting for you, changes happen, estimated review time. So yeah, it's cool. A lot of our customers are taking advantage of it. I want to give you the opportunity, So we're not just necessarily saying, “Oh, everything with Linear B is perfect”. Is there something you can't do with Linear B today that you would like to be able to do? And it's totally okay to say yes. [Chuckles]
Brent: [27:20] So I mean, I think like with anything, there's things that can be improved. I would say that one of the areas that would be really nice is the ability to immediately flag a particular PR such that it's not evaluated in the metrics, right from the UI. I think right now, there's various ways of doing that, you can use like different branching names, and regexes that map it or like filters, and sometimes you might see something, a metric that's out of whack, and you're like, oh, what's going on there, and you dig in And oh, it was this big, you know-we just added a new static analysis checker, and we had to redo like the entire code base, and that loses long running PR. And so it's not really indicative of anything about your system, right? It's-yeah, it's gonna throw off your metrics, because it's been open for 45 days and it's got a million lines of code and all that stuff. So, it’d be nice, just right click and say ignore that PR, and then have that percolate throughout the whole system. That's like an example of something I think could be improved on.
Dan: [28:21] Actually, that's a perfect example. Make it easier “Hey, these PRs these branches, something was odd about-we were working on them for a Hackathon” or whatever it was, get them out of there immediately. Great, Brent, thanks for sharing all that info about LinearB, I'm happy that we're able to help you so much, especially during this scaling time. I do want to bring it back to GRIN. Something that is on my mind, What are the challenges that you're facing now as an engineering leader?
Brent: [28:50] Yeah, for sure. As a market leader in a new emerging space, things come up. I would say organizationally, it can be really hard as you're growing, to institutionalize knowledge, that's just something that is an interesting side effect of hypergrowth. Right? Like you have something where, this is the way something's don, okay, and you just take whatever it is, use code reuse again, if you don't have that, codified and trained intentionally across your org, which is something that people again, might be like, “Why are we training on this process? That's super basic, or whatever.” it's like super simple. Why would you-you don't generally do that, like a code review is, here's the criteria, this is how we do it, it's pretty standard across the org or across industry. If you have more people that are new in your company in the last three months, then have been there for the last two years. All of a sudden, that standard tropes of how you communicate knowledge, no longer works and no longer applies. And so you can train everyone, and that's great, and now everyone knows the process, but then in six months, when again, you've doubled the size of your team, people don't know how to do it anymore. So that's one of the big challenges that I would say is building in methods so that people can fall into the pit of success, they can do the right thing, without really trying.
Dan: [30:15] That's really interesting. You brought up culture, and one of the I think, examples of, hey, this is not part of our culture, but here's an example of maybe a bad behavior. What is the engineering culture at GRIN? And how do you intend to evolve it?
Brent: [30:30] Culture is always one of those hard things to articulate and describe, it gets-especially if you're talking about from engineering, where we like to be very precise, and prescriptive around how things work and at the same time, we're individuals, and we don't like to be put in buckets. So I would say that, at GRIN in engineering, in particular, we have a very strong level of collaboration, and some engineering organizations are very hierarchical in the way that things occur.
Dan: [31:00] Yeah
Brent: [31:01] GRIN is an environment where it's-it takes humility to the next level, I would say that it's really important to listen and collaborate with your peers. And that means understanding that even if you've done something before, or a certain way, someone else might have a perspective that's valuable, that will improve it. And so being humble enough to hear to listen to your colleagues, to truly understand where they're coming from, and then build the best result without getting too attached to a particular implementation is very important for us.
Dan: [31:38] One thing that-that's interesting, actually you and I talked a little bit about offline, has to do with team setup. How do you organize your team that's scaling rapidly here, how is your team set up?
Brent: [31:50] Not like it will be in six months, and not like it was six months ago. So I'll tell you that, it's always changing and you have to be dynamic and flexible in that space. So the way it's set up is that we have, like, we call it pods, where you have an engineering lead, some engineers, QA, and associated product support, like Product Manager, design, all working in conjunction and in concert together to actualize some kind of feature capability. And so that is the cluster and grouping that then you have multiple of these pods working continuously, that’s one level of organization. I also think it's really important to appreciate the difference between releasing predictably new capabilities for the product and being extremely quick and responsive to your customers and to existing issues that may arrive, those are often conceived in conflict with each other, because if you're trying to be very predictable, then you can't necessarily be responsive, and vice versa, if you're very responsive, then that throws off your predictability. So we have a level of organization within the team to address that where I have a couple of different success criteria for different groups where one is really measured on response time and so they handle that type of activity where the other groups are measured on like predictability and ability to get the roadmap and the features in a consistent manner.
Dan: [33:17] Do you rotate engineers in that situation, or is a kind of just one team always more responsiveness and one team on the features?
Brent: [33:25] So particularly the teams themselves are built specifically for that, though we do move people between the teams, so they get different experience with that.
Dan: [33:37] Yeah exactly. I’ve seen that as a good practice. So how many engineers are in your organization today?
Brent: [33:44] The engineering team is about fifty people.
Dan: [33:47] And do you have like a growth roadmap of what you think it will be, maybe in a year or anything like that?
Brent: [33:54] A year is like a million [crosstalk] [33:56] years away.
Dan: [33:56] Six months. [laughing]
Brent: [33:57] Yeah, like a year in GRIN time, man, you might as well be talking about a decade. Hard to predict that far out. I would say that, yeah, we'll probably be double that in the next six months or so.
Dan: [34:06] We mentioned processes a little bit earlier, and you talked to maybe some stuff about the PR, but when you're thinking about doubling the size of the team, now you're really getting up there. Are there certain areas that you have in your mind, “Okay, I do want some processes and standards in a particular area”?
Brent: [34:23] It's a continual evolution, I would say that you're never sure 100% where the bottlenecks are going to arrive. You can plan and predict where ones are and if you try to address them too quickly, before the results are necessary to have in place, it could be just as damaging as not having it in place. Right? You have to be really intentional and careful around process in particular. It's really important for me when I think of “okay, what are areas that we need to put in place?” I'm building an environment that can be adapted and malleable as we're doing this that can just in time, iterate, improve, and then completely replace no longer functioning parts of our org, I would say building a system that is intentionally going to need change and be able to do that is what I'm focusing on.
Dan: [35:20] I mean, I think the lesson there is, don't be afraid to remove a process. You might put a process in place that's good when you're fifty engineers, and maybe you just put your ego aside a little bit like you were saying earlier, “Hey, this doesn't work for us anymore. We're removing that this process.” maybe you add one somewhere else.
Brent: [35:37] Absolutely, and at the same time, understanding that not everything can always be perfect, and that's okay. Sometimes it's okay, for some things to not be addressed, and that's something that's really hard for some people to internalize and understand that just because something's broken, objectively, doesn't give-isn't justification for spending time fixing it.
Dan: [36:00] Now, the last area that I want to touch on, you are going to be doubling your team size, something like that, significant growth. How do you think about hiring? Do you have a particular hiring strategy or what goes through your mind as an engineering leader when you need to double and bring in some great talent?
Brent: [36:17] It's a challenge for sure. I would say that hiring is always hard in engineering, because it's so important that people that you have, and the people that are part of our team, are our most advantageous part of the department, there's a lot of different things that aren't people and that's good, but the people really make the difference. So having a quick process that is able to ensure the right fit, I think is critical. And it really comes down to understanding there's a couple of different non negotiables, like around culture is a big one. Like, that's like something where you can immediately see that someone's a miss, it's harder to tell that someone's a match, but if you see someone’s a miss, and they have all the technical capabilities that you're looking for, it's really hard but I think sometimes you just have to not-not pick up that individual.
Dan: [37:15] Here's the thing, you're going to be talking probably to a lot of candidates, saying no quickly is not a bad thing. You want an efficient hiring process, the candidate wants that type of experience, say no early on, “hey, it's not a fit”. The one mistake that I have seen, I've been through a doubling of growth, and you got to talk to different people, and you might say, “Okay, the team leaders meeting with them first, then maybe the director, and then finally, maybe Brent, you need to sign off, or I need to sign off” sometimes if a candidate that would get to me, I could tell earlier on hey, I don't think you all are really that bought-in and let's not bring this type of candidate through the process. It's okay but say no early.
Brent: [37:54] Yeah, for sure, and it's also really important to just understand that there are different backgrounds and different paths to get to a really talented place where I would love to hire this person. And so that's something that I think often organizations struggle with is they look for a very structured criteria for what-what constitutes a great hire, and I'm not sure that it's that simple. I think that can work if you're looking for maybe one or two people where you find exactly the right peg-in-hole type fit, and sometimes the best people like come from places where you would expect.
Dan: [38:34] Brent, thanks so much for taking the time to sit down with us and talk about how you've constructed GRIN’s engineering team and your growth challenges, and you're building this all-in-one Creator management platform, that sounds absolutely awesome. It's been a great convo’, thank you so much.
Brent: [38:52] Yeah, yeah absolutely man.
Dan: [38:54] What should engineers out there know about GRIN, or where could they go if they want an opportunity to work on your team?
Brent: [39:02] Right on man. So I would say, first off, I wouldn’t just limit this to engineers, anyone that is looking for a great job at the market leading SaaS company and emerging market, it’s number one undisputedly in any metric that you have, right, you just try to come up with a measure of what we're doing, check out our glass door, just look at it. There's tons of roles, product roles, engineering roles, test automation, DevOps, there's endless opportunity here, please go check out grin.co/careers and take a look at what's available and if you're interested, definitely put your hat in the ring.
Dan: [39:41] Awesome. So yeah, really encourage everyone, check out the careers page at GRIN. Obviously, this is a rocket ship company. We have an engineering leader here that thinks the right way so probably some good career opportunities for you at GRIN [music play]s and also a quick reminder for our listeners if you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcast, please do so reviews are super crucial for our show that get discovered. Also be sure to join the Dev Interrupted Discord community, that's where we keep this type of conversation going all week long. I also want to say thank you to the more than two thousand of you who are now subscribed to our weekly Interruption newsletter. We bring you articles from the community, inside information, weekly pods, and the first look and Interact 2.0, on April 7, 2022. We have all of the links in information in the description below. See you all next week. And Brent, thank you again for being here.
Brent: [40:42] My pleasure. Thanks for having me.
[Music fades out]