It's finally here, the end of season 1 of the podcast is upon us! To celebrate, Santa is bringing something special - entrepreneurship advice for all the would-be founders of the world, ages 1 to 92.
Brian Singer, co-founder & CPO of Nobl9, sits down with Dev Interrupted to help us close out season 1 with a conversation on what it takes to found your own company. Having founded a pair of companies, one of which he sold to Google, Brian has a deep understanding of what it takes to successfully found and scale a startup. More than that, he knows what VCs are looking for.
In addition to our conversation on entrepreneurship, we also discuss Service Level Objectives, the ins and outs of Nobl9’s SLO platform and why SLOs and error budgets will become commonplace approaches in the industry, much in the same way we practice Agile today.
From the entire team at Dev Interrupted, we want to give a heartfelt thank you to everyone who has supported us and continued on this journey with us. Producing this podcast every week has been an absolute pleasure and we are so thankful for the outpouring of support we have received this past year. Expect big things - and even bigger stories - in season 2 of the podcast.
Have a wonderful New Year, we’ll return on January 8th with a HUGE episode for the official start of season 2.
Episode Highlights Include:
- Why VCs don’t like single founder companies
- Scaling beyond the first 20 employees
- What are SLOs?
- Understanding when tech debt matters
- The reason sales is the #1 skill for an entrepreneur
Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.
Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.
Listen and subscribe on your streaming service of choice today.
Transcription:
Conor Bronsdon: Guest host
Brian Singer: Co-founder and CPO of Nobl9
---
Dan Lines: [0:00] Hey everyone, Dan Lines here. I hope everyone has been having a wonderful holiday season. Today's episode marks the end of season one of the Dev Interrupted podcast. I want to give a heartfelt thank you to all of you who have supported us and continued on this journey with us. We owe a big debt of gratitude to our listeners. And I want you to know that hosting this podcast is one of the reasons I look forward to going to work every day. We are incredibly excited to continue bringing you more Dev Interrupted episodes in 2022. Have a wonderful new year, we'll return on January 8th with a huge episode. So far, our season two lineup is packed with talented guests, we really can't wait for it to happen. I look forward to welcoming you back on January 8th. Without further ado, allow me to introduce my Executive Producer Conor Bronsdon, who will be guest hosting this week.
Conor: [0:57] This episode is sponsored by Linear B. 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. Hey everyone, welcome to Dev Interrupted. This is Conor Bronsdon, Dev Interrupted Podcast producer and occasional guest host I'm filling in for Dan Lines this week. You may remember me from my previous guest appearances as host, episode forty-eight, featuring Henrik Gütle, and his discussion on developer velocity, and episode fifty Talking Engineering Leadership Screw-ups featuring our speakers from Interact. But today, I am going to be interviewing Brian Singer, the CTO at Nobl9, Brian, welcome aboard.
Brian: [1:45] Hi Connor. It's great to be here.
Conor: [1:47] And congrats, by the way. Twenty-one million dollar Series B funding round earlier this year. Seems like everything's going extremely well on Nobl9.
Brian: [1:55] Oh, thank you. That was really exciting for us. Although, given what were some of the fundraising has gone in the industry. It's like I think almost like a seed round these days, so.
Conor: [2:04] It's a little wild. I completely agree with you. Linear B raised sixteen million back in March, and we were ecstatic at the time, and still very happy with it obviously, but I talked to Dan and Ori Keren, co-founder on an upcoming episode. And one thing they said is the money's just flowing right now.
Brian: [2:18] I think part of it is there's just so many companies investing in software and turning themselves into a software company and so many great innovations and ideas out there that it's just a great time to be building software in general.
Conor: [2:30] We had Contrast Security on the podcast a couple weeks ago. And their leadership, I think it was Jeff Williams said this, he said, you know, software is what's enabling the most successful companies today, right? Every company is turning themselves into a technology company, just like you're saying. And that's what really is making the leaders in every industry thrive, so I think you're on point with that for sure.
Brian: [2:49] Yeah and I think people are realizing like, you know, C level executives are realizing that their ability to build software and to be successful and the-you know, productization of ideas and whatnot is core to their business. I saw the other day that I think it was Chrysler said we're going to make most of our money on software going forward-most of our margin and they're going to go from a thousand developers today to forty-five hundred in the next two years. That's like every-every company is going through that transformation if they hadn't already.
Conor: [3:16] Absolutely. I think that's a huge example, you know, I wouldn't have expected that. I do want to jump in and give our audience an opportunity to get to know you a little better. I'm curious, I saw you got your degree in computer engineering, you worked as an engineer for several years, and then you went back to school to get an MBA in marketing and entrepreneurship from MIT Sloan School of Management. What prompted you to go back and get that graduate degree?
Brian: [3:38] So I was really nerdy, loved engineering, I actually my first job out of college was designing Fibre Channel ASICs, which I enjoyed. But at a certain point, I realized to really, you know, have a lot of impact, it's not just the engineering skills that you need to have, but the softer skills as well, how to work with people and manage people have people coalesce around an idea. And I'd always been interested in sort of the entrepreneurial process, and you know, how great companies get started, and all of that, so I was attracted to what Sloan had to offer, and that's really why I went to business school.
Conor: [4:12] And I definitely hear that in the conversation we just had about funding rounds and how the industry is changing. It's clear that business background has informed decisions you've made in your career.
Brian: [4:22] Absolutely. You know, I think just being able to step back and look broadly at what changes are happening in the industry, and what markets are going to be interesting to try to solve problems in. But you can have a great idea, but if it's not solving a real customer pain, or it's not in a market that's growing, it's really, really hard to get a company off the ground, and that's something that was ingrained in us and business school.
Conor: [4:44] So I'm really curious, for some of the folks in our audience maybe are very much on the technical side, and are looking to kind of grow those skills, maybe found their own company like you have or do something else in business. What would you recommend for them, as far as learning to do things to pay attention to?
Brian: [5:00] Yeah, I think the number one thing is that you have to get really good at sales, if you want to be an entrepreneur, because most of what you do is sales. You're either selling your product or selling your company to prospective hires or to investors. And it's also I think, for somebody who has an engineering background, like one of the hardest skills to master, because we're used to thinking in terms of just like logic and flows, and you know, diagrams and sales is like psychology. And it's, you know, how are people thinking about what you're saying? And how do you get people excited about what you're doing? And you know, how do you sort of demonstrate leadership characteristics? So, that was probably the number one thing is just getting experience with the soft skills with how to, you know, represent your ideas to get people excited about them. And I would say, don't think of sales as a dirty word, if you're interested in entrepreneurship, but really embrace the science behind it and the psychology behind it. And you can even treat sales as kind of like an engineering discipline in that regard.
Conor: [5:56] I think that's a great point. And you've obviously clearly fused those disciplines well, your technical background and your-your business skills. This is the second company you've co-founded. You co-founded Orbitera, which was successfully acquired by Google. Can you tell us a bit about what Orbitera was and that process?
Brian: [6:12] Sure. Orbitera was a company we started in the earlier days of cloud, like 2013, when a lot of companies were just starting to move to AWS and were struggling to deal with Cloud billing Orbit-Orbitera itself did a couple things. One, it was a solution for channel providers who were trying to provide billing data back to their customers, when it was coming from cloud providers, we took some of the billing capabilities we had and used it for ISVs, to be able to build their own marketplaces of services that we would deploy onto cloud platforms. And that second part of the business that we had was interesting to Google, as they were building out their cloud business, because one of the things that you have to have, if you're a cloud provider is a lot of software that can run on that cloud that's been tested, validated and is supported. So, Google acquired us in 2016, to help build out that marketplace business, and so it was a great ride at Google doing that sort of the I would still say the early days of cloud in the early days of growth out that for that company. Yeah.
Conor: [7:12] What were the terms of acquisition?
Brian: [7:15] The terms, I don't know how much I can say, [crosstalk] [17:17] sorta publicly around the terms But- but I…
Conor: [17:17] Okay, fair enough, yeah.
Conor: [7:21] My SAS sources say it was around a hundred million dollars, which is fantastic.
Brian: [7:25] Yeah, I can neither-neither confirm nor deny, but I can say that the acquisition process with Google was, you know, something that is both a lot of fun and really challenging, because all of the things that were important to you, as a startup, those-those shift, right, when you're part of a company, like all of your objectives [crosstalk] [7:46] and all of your goals…
Connor: [7:46] A massive company.
Brian: [7:47] Massively shift right, and so changing your mindset of sort of a founder entrepreneur, you know, how do I get to this milestone of MRR, how do I? So now you're shifting to, okay, we have X number of customers, how do we build things that are actually going to be useful for those customers and what they're trying to do with the Cloud Platform? It was, I think, one of the one of the greatest experiences I've had definitely.
Conor: [8:11] And you spent three years at Google post acquisition prior to founding Nobl9, correct?
Brian: [8:16] That's right. Yeah.
Conor: [8:18] What are the things you feel like you learned from that experience there? As you point out, you transition from this entrepreneurial role building a company to Okay, now I'm part of this massive organization. How did that affect your perspective?
Brian: [8:29] It was, I think, really interesting for me to see how Google treats the software engineering process. As a startup, you're really focused on being agile, moving quickly, shipping features quickly, that tends to build up a lot of tech debt, right, over time. And this is a topic you’ve discussed on this podcast, but as you move fast and cut corners, you get a lot, a lot of tech debt built up. Google is-I would say it's very careful about how software is built, and so it takes-it takes longer, it's more of a waterfall type process. But the end result is typically something that can scale to Google scale, right? Like Google's not going to ship software, that is like going to fall over once it gets past the first thousand users because you know that, you know, immediately this is something that's going to go into the hands of ten-thousand, hundred-thousand, million user, billion users, right? So, you have to you have to build for that scale from day one. It wouldn't make sense for a startup to do that, because you never get to market you would be [crosstalk] [9:28] building for a million users. But you're just focused on getting your first one.
Conor: [9:28] You need to move fast.
Brian: [9:31] But-so, from a sort of-looking at the different ways to build software and to sort of treat that development process. It's a very different mindset, which has its pluses and minuses, right? The-the downside of that is that it takes a lot longer to ship something. There's a lot more red tape, right? You have to go through a lot of approvals to ship software at Google, everyone weighs in, right? Legal team, product team, SRE team. I think that experience was, coming from a startup and then doing it the Google way, which, you know, to be fair, like a lot of other companies follow that as well. And a lot of engineers have left Google and brought those practices elsewhere.
Conor: [10:08] Right.
Brian: [10:09] But that was a great learning experience.
Conor: [10:11] You mentioned technical debt. We recently had Paolo Rosado, the founder of OutSystems, on the podcast to discuss tech debt. How do you think tech debt applies the notion of rethinking software reliability, which is something we're gonna talk about shortly with Nobl9?
Brian: [10:26] Yeah, so I think, you know, one of the things that's interesting about tech debt is that it like-it doesn't always matter. And figuring out when you should address it is really figuring out like, when does it actually impact my business? And I think it impacts the business in two ways. One is you build something that can't scale to the size that it needs to now because you didn't have to build it with as scalable of an architecture, you know, maybe you had a Kafka configured a certain way. And the question becomes, like, when do I need to go back and address that, because if I tried to do it for my whole application, I'll never ship another [crosstalk] [10:57] feature, I can spend all day just, you know, working on scalability.
Conor: [10:57] It’s all tech debt, yeah.
Brian: [11:00] And so we need some notion of whether we're meeting the needs of our customers from a scale standpoint. And typically, you can start to see that in some of the signals that-that we use to measure reliability that we call service level objectives. So, if you create goals for how latency or whatever you're trying to do, and you start to measure how you're doing against those goals, you can start to see when tech debt needs to be addressed. The other side of tech-debt that is like when it slows down developer productivity, right? You'd have some like, really hairy piece of code, or some really hairy, you know, API handling mechanism, and every time you want to go add a new feature there, it's-it takes eight times as long as it should. That's also, you know, a signal that “Hey, we need to go look at that.” and you know, it does come back to reliability because if code is not well organized, or needs to be refactored, and it's more likelihood that when you touch that you're going to ship a bug that's going to show up in those signals as well.
Conor: [11:55] Yeah, a couple months back before the Paulo episode, we had two senior staff engineers from Google on, Hyrum Wright and Titus Winters. And they talked a bit about this as like, how do you decide when to prioritize tech debt? Based off of is this the most impactful use of my time? Or am I just kind of defaulting to oh, well, this kind of needs to get done?
Brian: [12:11] Yes!
Conor: [12:12] And I'm definitely hearing you resonate with some of their thoughts around that.
Brian: [12:15] Yeah, exactly. That kind of ties to why we started Nobl9, because when I came into Google, one of the things that you have to do is establish SLOs for your product. We knew that there were some areas of the product that-that needed to be rearchitected, right, and once we created SLOs against, you know, that were measurable goals against those areas, it helped us pinpoint, like, where to actually spend our resources. If you're going to go take six months to re architect some critical piece of infrastructure, you better be sure that you really need to!
Conor: [12:45] Yes! [laughing]
Brian: [12:46] And then you better be able to measure that because going back to a CTO or CEO even and saying, Well, we spent basically a couple million dollars refactoring this, but and I have no data that shows that we needed to do that it's not a recipe for success.
Conor: [13:01] Yeah, I can imagine. It definitely sounds like that experience at Google helped inspire you to co-found Nobl9. Can you tell our listeners a little bit more about Nobl9 and what you do?
Brian: [13:11] Yeah, sure. So Nobl9 is a platform that enables you to build, manage, and run your operations using service level objectives. And what we do is we take the signals that you have today from your existing metric systems, bogging, etc., we take that data in, we normalize it, and we apply whatever objectives you're creating for those services, whether they're user journeys, or actual, like API services are sort of anything in between. And then we-we provide the alerting, reporting, etc., that operates with sort of SLOs at the core. The reason we built that was we started using SLOs, when we were at Google. And from the first day, I sort of worked with SRE as a product manager to create the first SLO for a platform. I said, this is-I wish I had this before we were at Google, like this is amazing. The things that were getting me phone calls from angry customers at 11pm were things that were now showing up really clearly sort of objectively that can be analyzed, and so when we looked around, we said, well, there really isn't, you know, there are very simplistic SLO tools out there that are sort of tied to different metrics system, but nobody's trying to solve this sort of holistically for your enterprise that has a plethora of observability tools and metrics systems, and environments. It's actually kind of crazy, like the average enterprise, we were talking to one of the analyst firms out there and they were saying that the average enterprise that they see over one-hundred million or two-hundred million in revenue, has something like thirteen observability systems.
Conor: [14:48] Wow! Yeah.
Brian: [14:49] That's the average. So, I think for us, it was sort of realizing well, if companies want to-want to adopt SLOs as a sort of fundamental way that they-that they drive operations, they need a lot of help in terms of managing the data that's coming in and making it easy for an engineer-an individual engineer, individual SRE to create those SLOs without having to create all the tooling that goes around it that's like specific to each individual system that they're using. And so that was the sort of the genesis of Nobl9
Conor: [15:19] Awesome. Thanks for that. That's a really interesting story, it's clear that you found this problem that you were experiencing and said, hey, like, we can solve this. I do want to pause for a second and make sure that we define SLO, service level objectives for anyone in the audience who might not know and kind of explain their relationship with SRE. Can you do that for us?
Brian: [15:28] Sure. So, you know, a service level objective is basically just saying, my system should be doing something, and that's the SLI, that's not, you know, what it should be doing, it should be doing something some percentage of the time, right? So, you could say, this API should respond to, you know, a valid request within two seconds, 99% of the time, right, that's a very-that's a very basic SLO, and then we would look at that, like on a on a thirty-day rolling basis. You could have something for maybe a sort of a batch system that says “Hey, this job should complete successfully and return correct data within an hour, 99% of the time.” Right? So you're really just defining in terms of you know, what the goal is, from a, from a customer standpoint, if you look at maybe more of a front end user journey, you might say, you might have like a login screen, right, you should say, a user with a correct password should be able to log in and see the homepage load within two seconds, 99.9% of the time, right, whatever it is. And then there's some complexity around like set, creating multiple thresholds for the long tail and all of that, that, that starts to get pretty, pretty interesting, but that's-that's the basics of service level objectives. And then what gets interesting is, if you take the inverse of that objective of that 99%, what you're really saying with that SLO is 1% of the time, I actually want it to fail, I'm actually willing to accept 1% unreliability, and the phrasing that we use for that 1% is the error budget, right? I have an error budget of 1% for this service level objective.
Conor: [17:17] And that will vary between objectives.
Brian: [17:19] Exactly. And then what's nice is you can kind of change your frame of mind in that we're not actually trying to hit some, you know, number of nines of availability, we're trying to burn less than a certain amount of error budget, and actually, it's a good thing to burn that error budget. Because if you're not, you're-you're actually, potentially introducing other problems. There's a very famous system at Google, I think this has been publicly talked about called Stubby, that basically had a certain objective in terms of their availability that was not, you know, five nines, like probably two nines or three nines, but the system never went down, right? They were never burning that error budget, because it was a pretty straightforward system. And so, others started to take dependencies on them. Basically, assuming a much higher level of reliability than then the system was being managed to, right. If you want to get to five nines, for example, you got to have a team of at least you know, eight, SREs, you have to have somebody always within five minutes of a keyboard, right? So, if you're not doing those things, it's very dangerous to assume to take a dependency.
Conor: [18:26] So if Stubby goes down suddenly.
Brian: [18:29] Yeah, yeah, and so there's teams at Google that will even cause outages, and you know, people call it chaos engineering or whatever, just to burn that error budget, right? You want to actually-you actually want to make your system as-as unreliable as you can. And that is, you know, that's kind of how you drive efficiency.
Conor: [18:45] Fantastic. That's a great explanation. So, it sounds like you think there's something kind of broken in the current approach to software reliability.
Brian: [18:53] It's not so much that it's broken. It's just kind of flying blind. There's just not the level of instrumentation that people need to make good decisions. So, it's kind of like, should I pull up on the throttle? Or should I push down? Like, we don't know because we don't have the right signals to tell us. So, we're just, you know, trying to get data into the hands of individual engineers and engineering leaders, leaders at companies to make better decisions about where to put their resources.
Conor: [19:20] And it sounds like you think this all benefits developers, right?
Brian: [19:23] Yeah, at the end of the day, definitely! Because it really helps developers in two ways. The first is it can help alleviate a lot of the stress from-from on-call and incidents and getting too many pages because if you're tuning your reliability to, you know, what the customer actually needs, and you're still not able to hit that, then clearly you have a resourcing problem or something like that. But too often teams are trying to hit goals that are totally arbitrary, right? And then they're under resourced for that.
Conor: [19:55] I’ve been there.
Brian: [19:56] Yeah. And everybody's been there. And then the other side of the coin is the tech debt, right? It's like really hard to get product managers and the-sort of the business to pay attention to tech debt because the impact of it is like not-it's not visible, well, this is a way to get really great visibility into the impact of tech debt. And then you can go-you go prioritize it. And from an engineer, I mean, all those surveys, say, you know, quality of life is basically like, we have to spend a certain amount of time not shipping new features, and just dialing that in is a very hard thing to do.
Conor: [20:27] Yeah, I think this idea of how do we explain to the rest of the business, why this is so important? And how do we explain to our teams, and our managers, and our leads even why it's so important, it's something that is being seen more and more, as I talked about earlier, technology companies become the norm. And particularly with like these older companies that sometimes maybe don't have this culture built in from the start of hey, you know, we start with software, we this is how we build translating that so that the sales team and the marketing team, and the CEO all understand why it's so important is really crucial. And honestly, it's one of the reasons we're building Linear B on our end is how do we enable the engineering team and the engineering leadership to demonstrate to the rest of the business, this what we're working on, this is the value derived? And I think we're taking different approaches, but it's all part of the same problem space in some ways.
Brian: [21:19] Right, right. I mean, and what you're doing is definitely, like equally important, because you also want to answer the question of, you know, what, why are we doing what we're doing? Like, what is-what is the [crosstalk] [21:29] actual costs?
Conor: [21:29] It’s nice to understand!
Brian: [21:31] Yeah, exactly. For a lot of business leaders that didn't grow up in software companies, it's kind of entirely new. It's like the industrialization of software.
Conor: [21:39] Yeah.
Brian: [21:40] So, it's-it's a pretty interesting time to be working on it. You know, the other area that it's impactful, you know, companies are adopting this SRE model, so obviously, you have developers running, operating, taking call for their own services.
Conor: [21:53] Right.
Brian: [21:54] You have, I think, something of a shared model, where site reliability engineers are taking some of the call or some of the operational load. And then you have models where SRE teams are 100%, responsible for, you know, the operation of the service for certain critical services, where maybe an individual developer doesn't have the view of the entire service, right, but-but the SRE team does. And in those situations, SLOs are critical, because you have a mismatch in priorities between the people that are shipping features, and the people that are actually responsible for the reliability of the software. And the-the SLO serves as kind of like a governor between those competing priorities, like, ship fast, you got to ship for the customer, but you can't just dump it on this other team that is now going to be paged six times a night, because that's going to burn them out.
Conor: [22:42] So it sounds like you believe service level objectives and error budgets will become commonplace approaches in the industry.
Brian: [22:50] Yeah, I mean, that's the bet that we're making as Nobl9. And I think it's consistent with what we're seeing happen. It is, I think, partly cultural. So, you know, folks have to get comfortable with it. And then [crosstalk] [23:00] the tooling helps quite a bit as well, so that there's not as steep of a learning curve, and that's obviously where we're applying a lot of our a lot of our know how
Conor: [23:00] Sure.
Conor: [23:08] I do want to ask a fun question here. Is it true that you name all of your product releases after the periodic table and the noble gases?
Brian: [23:16] That’s right, yeah. So, when we chose the name Nobl9, one of the reasons we really liked it was because it sort of made us think of the noble gases, which are the most stable and reliable gases out there. And so, our internal product releases we always named after-after noble gases, so we had Helium, and we had Argon release and so on.
Conor: [23:37] Awesome.
Brian: [23:38] And then we were naming a release of our software that was going to be intended to be used, like as a free trial, self-service and all that. The internal name was Hydrogen. And we were looking like, what are we going to call this on the website? Is it, like, the Nobl9 starter pack, or the basic edition or the free edition? And someone said, “Well, why don't we just call it Hydrogen? Like, that's a pretty cool name.” so, we went with that and so that-that's why that's now a public name.
Conor: [24:02] I like it, that's really fun. Let's take a moment to zoom out a bit, I want to ask you some specific questions about your approach to leadership. Obviously, you've been a very successful leader in multiple organizations, as a lead on product, lead on engineering, you've got that business background you're bringing to the table, having founded two different companies in Orbitera and Nobl9, what advice would you give to future early stage founders with a product background or a technological background who might be listening to this podcast?
Brian: [24:29] I think one is like know what you're good at and what you're-what you're not great at, right? And then and then hire to fill those gaps around you. So, for me, it's always been like, you know, sort of a lot of introspection of, where do I need other leadership to help us go faster as a company and whatnot? The other thing that's I think really tough as a startup founder, you tend to be like really type A you know, go getter let's-let's do it ourselves, is like you can't do everything yourself, and actually, if you try to do everything yourself, you're probably building an organization that's not gonna scale past a certain point. I think it's why like a lot of companies can get to the twenty, twenty-five-person stage. And at that point, it becomes really, really hard to scale because probably the founder’s been doing everything. And then and then sort of giving those jobs to other people becomes tough because like, all the knowledge around how to do these things is has, you know, [crosstalk] [25:20] stayed inside one person’s head.
Conor: [25:20] It’s all tribal knowledge.
Brian: [25:22] It's all tribal. It's all tribal. Right. But it's-I think it's like specifically a problem for founder led companies, especially, you know, if you're bootstrapping or something like that. The other thing, like, I think is important is to understand how prospective investors and prospective employees like see the opportunity, to be really-really honest with yourself, just like there's like different phases of a person's career, there's like different phases of like how backable you are as a founder, right? If you've only worked for big companies all your life, and you're coming out and you're doing your first startup, there's certain VCs that will just say, like, “Hey, it's tough for me to back you-like, show me that you can do it, right? Before I write a check.” If you're coming out of like a startup, or you-you know, you've worked in that environment before you built those relationships, or you know, it's your second company, people look at you a lot differently, sort of having that, that honesty with yourself, I think is super important. And then finally, don't be afraid to get out there. Pretty much everybody that has been through it wants to help people that are going through it. And so don't be afraid to ask for help, to ask for mentorship and guidance and advice. People want to make connections and want to grow the next, you know, the next crop of great companies and founders and help them grow. You know, I think that's one of the most exciting things about being a part of sort of the entrepreneurial community. I think by and large people, people just applaud all the success that everybody has, there's not a lot of bad blood out there.
Conor: [26:46] So let me ask then, if someone's listening to this podcast, and they're thinking, “Hey, I'm really enjoying this episode with Brian, and I'm thinking about founding my own startup, would you want them to reach out to you on LinkedIn?
Brian: [26:57] Yeah, absolutely. Hit me up on LinkedIn, hit me up on Twitter. If you follow me on Twitter, I'll follow you back. And you can-you can send me a DM you know, and if you really want to, you can probably find a way to email me directly. I definitely would love to chat.
Conor: [27:10] Very cool. I also want to ask about co-founders, I know I heard you talking about hiring to fill gaps in your own knowledge or to find specialists who, you know, can go deeper than you can. What about finding the right co-founder and the mix there?
Brian: [27:24] That's probably the most important thing. A lot of VCs don't like backing single-founder companies, because they basically say if you can't sell your vision to one other person and make them a co-founder, how are you expecting to hire anybody? Or how are you expecting to sell the vision to me, so it is a good validation. Nobody is perfect. Like, I've never met, like the perfect entrepreneur that can do the go to market, and you know, write code in his basement, and like, there's not enough time in the day, right? So, you have to think about where are you going to focus? You know, where are you uniquely suited to focus your time to get the most out of your product and yourself and whatnot, and where can you bring in really good people to help in other areas? Even if you can do it right, you can still bring in people to help make things go faster.
Conor: [28:06] I love that. Let's dive a bit more into engineering here. Specifically, since we've talked a lot about building products here, what are the keys to success as an engineering leader in your mind?
Brian: [28:15] I think it is having the right engagement with the team, but also the right engagement with more senior leadership. So, you know, I'm expecting a good engineering leader to be able to communicate across the organization, right? Communicate priorities, progress, and everything else. That's the number one, I think characteristic of a good leader is just the ability to communicate and-and to do it effectively. And then I think in-you know, in terms of managing a team or being an effective, you know, there's a couple levels right there's; are you the person that's like actually, like, managing a team of fifteen or twenty engineers, right after that, it's-it's pretty tough. If it's down at that level, then it's, you know, somebody that can act as both a mentor and a coach, but also help with prioritization and task management, things like that, more of a micro level. But then if we're, if we're talking about somebody that is, you know, more of a director or like a VP level person, the number one thing is just is-is recruiting culture, somebody who can build a culture that brings out the best in people and you know, inclusivity, and building like a diverse team is, I'd say, the most important thing for sort of director VP level engineering leader.
Conor: [29:25] Fantastic. Those are a great piece of advice. And that I want to close out with two questions that we try to ask every guest, we'll start the first one. Are there any failures that you overcome that you feel like you've learned a lot from?
Brian: [29:38] Sure, you know, I wouldn't necessarily characterize the first company that we did as a failure. We got acquired by Google, of course, but still learned a ton, right, about how to grow an organization, how to raise money, how to raise capital, and like, I just, there's no way that you get those lessons without going through it. I think as-as entrepreneurs, like we’re kind of-we’re kind of failing and succeeding constantly, you know, [crosstalk] [30:02] we’re failing at one thing-
Conor: [30:02] You got to learn from it.
Brian: [30:03] Yeah, we're failing at one thing and succeeding in another, like, maybe we didn't get that hire to come join, right? But we're gonna learn from that, you know, why didn't they join? Was it something we did in the interviewing process? Or, you know, you have to, unfortunately, sometimes let somebody go because like they weren't a fit, or they decided to leave. I think just like learning from those things that happen on a day-to-day basis that it's not always going to go, well. You're not, you're not going to go win every customer deal that you want to win. But being honest and honest with yourself and being introspective and learning from that is critical.
Conor: [30:34] I think that's really poignant to point out, and in particular, the thing that I heard that I think we underestimate a lot is the impact of losing that person from your team, right? Like, we obviously all care about retention. You know, building a culture is important, like we've talked about, but it can hit you hard as a leader when someone that you recruited and maybe mentored at the organization says, “Oh, it's my time to leave.”
Brian: [30:58] Yeah.
Conor: [30:59] And sometimes it's just a factor of like, where they're in the career, they’re ready for that next step, and you don't have an opportunity available for them at the right time. But other times, it feels like a reflection on like, oh, I've made a mistake here somehow. Or maybe I hired the person who wasn't a good fit.
Brian: [31:13] Yeah, I mean, you-you look at it, like was it-was this destiny, right? Or were there things that we did along the way that, that-that led to this particular outcome, there's plenty of times that it's just like the wrong person in the wrong role and it's just not a fit, and you got to move on, or you miss things in the hiring process. So, I think those are great opportunities, when people leave to take a really deep look at all your processes. Was it how we went about hiring right? Was there anything there? Maybe this person, you know, should have been a great hire, right? And then, was there anything in onboarding, right? Did we not get the right resources? Did we not help them become a part of the culture? Was it not a cultural fit for another reason, right? Were they experiencing bias at work, for example?
Conor: [31:54] Sure!
Brian: [31:55] Those are great opportunities to sort of harden your organization. And you're not always going to like the answers that you find necessarily, sometimes the reflections on-on you as a person, if we're being honest, like, that's one of the hardest things about being the founder of a company is that the company becomes a reflection on you as an individual. And I think that's why it's a stressful place to be for a lot of people. It's not for everyone, for sure. It's why we also try to actually celebrate the fact that it's okay to fail as a founder, right?
Conor: [32:25] Right.
Brian: [32:26] Because so much of it can be wrapped up in like your own self-worth and whatever. But there's plenty of companies that were great ideas started by great founders, and the market wasn't there, or, you know, the-the right product didn't get built. And it's like, it's just not it's not a reflection on the person as an individual.
Conor: [32:42] I think that's a really good consideration, particularly what you're saying around, you have to be really honest with yourself, you can't let your blinders, or your preconceived notions, affect that you have to actually take the lesson and really learn from it.
Brian: [32:55] Yeah, and you know, engineers, I think they don't want to fail, right? That's what you know, like, [crosstalk] [32:59] you talk to great salespeople, they get told no forty-five times a day, and yes, one time a day, and that one yes is enough, right, to get them to the next day, right? But-but there's a lot of people it's not in their personality told no forty-five times until they get to the one yes, so.
Conor: [33:12] It’s hard.
Brian: [33:13] And I think that's pretty common with engineers who are used to being able to find the solution to a problem that's in front of them.
Conor: [33:18] Right, they want to fix problems. I think that makes sense. Speaking of engineers, the other question I'd like to ask is, what metrics do you use within your engineering organization?
Brian: [33:26] Yeah, so you know, we-we use some pretty basic story pointing, like we're not-we're not trying to basically grind our developers down with story points. But we are, and they’re on board with this like, we are trying to understand the relative cost of certain things that we're building, right? And, you know, if we have two capabilities that we want to-that we want to launch, and we think they're going to have equal impact on the customer, and one of them is twenty-five story points, and one of them is three story points, like we're going to do the three-story pointer, right? So, we're using that to make sort of prioritization decisions. But you know, we're not using it and I would discourage people from using it to try to track individual engineers’ productivity, because I think it's-it's a pretty terrible way to do that. We use it also as an input to try to track the cost of doing various things. We want to understand the ROI of a particular feature, you got to understand what would it cost you to actually build it? Like a lot of the things that we do is we build integrations to different systems, right. So, we built some-some internal tooling to be able to understand what the cost is of like building a particular integration does, and we're using that pretty extensively.
Conor: [34:33] Yeah, I definitely agree with what you said about avoiding measuring individual developers in any sort of like sack ranking or anything like that, because all it does is undermine your culture and undermine your team and create negative competition that actually damages what you're trying to get done. That's something that I know at Linear B we really try to avoid and encourage everyone to avoid. So, I totally agree with you on that.
Brian: [34:56] Yeah, yeah. But there's definitely a lot of great tooling out there that is improving the metrics that we have around engineering and velocity and whatnot. It's an area that we're interested in learning more about.
Conor: [35:07] Very cool. Well, Brian, thanks for taking the time to sit down with us and talk about Nobl9, SLO, how you're thinking about reliability and rethinking it, and also what it took to found two different companies. It's invaluable advice, and it's been a great conversation. I do like to give our guests an opportunity at the end of the podcast to close with like a call to action. What do you want engineering leaders and team members listening to this to take away from the conversation?
Brian: [35:31] Sure. I mean, if you're not using SLOs, today, it's incredibly easy to get started with them. I'm definitely gonna plug my own product at nobl9.com,
Conor: [35:38] You should!
Brian: [35:39] You can sign up for Hydrogen, you can start using it immediately. You're probably using a metrics or data-store system that we support today. So, there's like really no barrier to getting started. And if you need some help figuring out that first SLO reach out to us and you know, we'd love to help you out.
Conor: [35:55] Fantastic. Definitely check out Nobl9 as they call it on their website, “It's the cheat code for SLOs and error budgets.” I love that. And a quick reminder for our listeners, Dan says it every week, but if you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcasts, please do so! Reviews are a crucial way for our show to get discovered and help continue to create great episodes like this for you. Also, thank you to everyone in the Dev Interrupted Discord community. We keep the conversation going all week with daily discussion topics. And the two-thousand of you, actually more than that now, are now subscribed to our weekly interruption newsletter. Thank you. [Music starts] We bring new articles every week from the community, inside information on weekly podcasts like this week's with Brian, and the first look at our Interact conference. Interact. 2.0 happens April 7, 2022. I can't wait to show you what we have in store. We'll have links to all this and to Nobl9 in the description below. And Brian, thanks so much for coming on.
Brian: [36:46] Thanks Conor.
[Music fades]