In the latest post from our series on Building the Future of Car Care, Software Engineer Clay Kelly talks Power Rangers, taking ownership, and the upside of failure.
Tell me about when you came on board with NuBrakes. What attracted you to the role?
I joined in January 2021, so it’s almost been a full year now. I originally was at a big corporation and was just kind of sick of the politics. I wanted to move to something smaller, something with more responsibility. I wasn’t actively looking for a new job, but I knew Walker and Collin from college, and I saw them post the job opening. When I interviewed, they kind of blew me away with the product and everything they were doing, so I was pretty excited to join.
A year in, what have you learned about excelling at a startup?
In a startup environment, and even generally speaking, I think growth comes from having to own your own problems. I came from a big accounting firm with thousands and thousands of employees. Often, there was a whole team working to solve the same issue, and maybe your voice didn’t matter as much.
Here, if you have an issue, it’s “find a solution.” There’s a sort of general knowledge base improvement that comes from having to find ways to unblock yourself. But responsibility can be a two-edged sword.
I love it personally -- this concept that you own this piece of work that’s actually going to have a lot of value to the business right now. Everything is really fast-paced in the environment we’re in. Anytime you release something, it’s going to go out there, and it’s going to be used. Obviously, that can be a little stressful sometimes. You have to be extremely particular about what you’re coding, since everything has an impact.
I think the positives, though, are just the culture we have, and the coworkers. Just because I don’t have a large team doesn’t mean no one’s going to jump in and help. There’s also obviously a ton of opportunity here. There’s just so much growth to build on.
So, what have you been working on lately? Anything cool?
We have two pretty big projects that we’ve been working on. We have something we call Megazord, which is essentially a pricing system that allows our sales agents to pull in different products and services to generate an accurate quote. It’s really focused on our sales team and making their day-to-day lives easier. I’ve also been working on a scheduling algorithm, which is one of the building blocks toward allowing our customers to self-book appointments through an online portal.
Eventually, we want to get to a point where a customer can go online, tell us their symptoms, select the specific services they need for their vehicle, and book an appointment to get the repairs. What we’ve been working on are really just building blocks of that.
“Scheduling algorithm.” That doesn’t sound complex at all.
Yeah, there are a lot of different components that go into how we choose which technician we’re going to send and how we know we have availability at the time that the customer wants to book. Tying Megazord into that, which is our pricing system, we also need to account for what services they want done. It’s a pretty complicated system that we’re going to be iterating on for a while.
Let’s talk about Megazord. Where’d the name come from?
Megazord is actually a Power Ranger robot. Our head of product, Josh, has a little kid who watches Power Rangers, so I think he thought of it. In the show, all of the Power Rangers come together to make this robot thing. In our world, we’ve got all these separate pieces coming together into one technical component that we use to solve problems on the customer side. So, that’s why we call it Megazord. It’s really a team thing. We all got sent these little Megazord cartoons.
Walk me through a typical week as a software "dev."
With devs, a lot of the way we schedule our week has to do with trying to prevent context switching. What that means is, when you’re working on something, once you get deep enough into it, if you have to pull your attention away from that, it’s kind of compounded in the time that you spend getting back to where you were. That’s kind of a big deal as far as our velocity as an engineering team and how much you can get done.
To allow for that focus, generally, our meetings are pretty sparse. We work in two-week sprints, so, every day, we start with stand ups, which are just what are you doing today and what did you do yesterday. Then, we have a refinement once a week, which is talking about new things that have come up. We also have some one-on-ones, usually with your manager, which tend to be you focused, career focused. Other than that, it’s your sprint work, which is what you need to get done within the two-week period. And then bug work, which is anything that just kind of pops up.
What excites you about the work you’re doing?
There’s a term that I’ve heard. It’s kind of like drinking water out of a fire hose. There’s so much I have to learn for everything we build. We don’t really have a reference for what we’re doing. The roadmap hasn’t been built yet. And that can be awesome. There’s just so much here.
In the short term, the company as a whole is really focused on growth. As devs, everything we do is to try to help them move in that direction. Longterm, we want our customers to have the most seamless and trustworthy experience in auto repair that we can possibly deliver through technology.
There’s a huge lack of technology in the industry we are in, and so our company has the ability to be a lot more than it is. For now, it’s brake repair, but I think it’s important to emphasize that we’re not a brake repair company. We’re a tech-focused company, and there are a lot of areas within the industry that we can penetrate and where we see opportunities for transformation.
Even the things we have built so far could have a lasting effect on the industry.
How would you describe the culture at NuBrakes?
On the spot, I’d say the best words I have to describe the culture here are “open” and “honest.” When I say open, what I mean is, if you have something that you think is important or that you want to talk about, say it. Speak your mind. Even if you think it’s a dumb idea. Some dumb ideas have spawned really good ideas. Also, failing is good. Fail fast, and then let’s move on to something that is going to work. Just don’t be afraid.
With honesty, it’s the idea that, no matter what, you’ll always have feedback. This is more of a personal thing, growth and career-wise. It’s a really “don’t beat around the bush” kind of culture. For example, every week we have our All Hands meeting, where we’re explaining what’s happening around the entire company, and it’s not always “Oh, our numbers are good here.” Walker, our CEO, is going to tell you exactly how it is, whether it’s good or bad. That really leads the entire company along the same vein. Let’s be honest about where we are. Let’s attack things.
As a team, as a startup, we’re still defining our culture--and we have a lot of room to define that culture. We have the ability to switch things up a lot faster than when I worked at a corporation. We work in the same kind of agile way, but if we see inefficiencies, we have the ability to pivot away and refine our processes.
How do you deal with those particularly challenging days, when you’re up into the wee hours fixing bugs?
I can actually give you a concrete example of something that’s happened this week. We’ve been dealing with a bug for about 22 days that has been an absolute nightmare. We don’t have to get into what it was, but long story short, the fix is something that nobody’s going to really notice from a business standpoint. On the front end, everything’s just going to work the way it was. But on the back end, it’s been this ticking time bomb. So we’ve been sitting here, working really late nights for a couple of weeks now, and it’s been super stressful. Now that it’s fixed, though, it’s this really celebratory mood among the team. I think we all had beers last night. Like, thank god that’s over.
We have a really great team, and we’re very good about helping each other. There’s no blame. It’s just, how do we fix this? And when you fix something, even if no one outside the team notices, we’re going to celebrate that you did something good. I mean, I had somebody who wasn’t really even working on it ping me last night at like seven just to ask, hey, how is everything? The bug’s fixed! If we were in the office, I think we would have all been at a bar.
If sleep weren’t a thing, and you had eight extra hours in the day, what would you do with them?
That’s an interesting question. I think most people might have said travel, but I just thought, oh man, now I can work out and, like, cook dinner. Get chores done. I guess a little more fun answer would be, I would probably work on my own application ideas.
What have you been most intentional about when it comes to your professional development?
I think, for a dev in general, communication skills, people skills, are equal to tech skills. Knowing how to program, architect, code things -- your general knowledge base is obviously very important, but that comes with time. People skills are something that can set you apart early on.
I can describe something in a very technical way, and you’re not going to understand it. A good dev can articulate an issue in a nontechnical way so that a stakeholder can glean the problem and why it’s a problem, so you can both agree on a solution. I think students who come out of college and can communicate effectively are going to get to success quicker.
That goes for cross-team communication, too. There are what I call “bullet list devs,” because they get a bullet list of requirements for a new technology or feature, and they just start coding to that list. They don’t ask for clarity or context. I think it’s critical to ask questions. Hey, why are we doing this? What's behind this? So you can understand what you’re actually building. If someone else is working on something similar, you might be touching the same code, and being on the same page with that person is going to be important.
Knowing what you know now, what should a dev ask their future boss before accepting a role?
I think that depends on your own experience and what you need out of the job. So it's important going into an interview to really know yourself and what you want. Obviously, you should consider the knowledge you might need for that role. But it’s also good to have an idea of your ideal work environment in terms of how much you want to work, what kind of managers you work well with, if you like big teams or small teams, and so on. You can learn a lot of that stuff in college. I think knowing those things will naturally lead you to questions that can help determine whether or not you will fit the culture.
The other thing I’d say is, don’t be afraid to ask about business metrics and money. If you have a question, and they don’t feel comfortable asking it, they won’t. So if you’re curious about how the business is doing, ask. Worst case, you get a generic answer. Best case, they’ll tell you how it is, which is what our company would do.
Anything parting thoughts?
What I think is really important for people to understand, especially if you’re considering joining our team, is that there's what you do to make revenue, and there’s who you are as a company.
My last gig was a tax application. (So that’s boring.) And brake repair maybe doesn’t sound like the most interesting thing, but that’s really not what we’re about. It’s a very innovative group here. We’re building things in the industry that have never been done before. It’s a future thinking mindset of, how we can actually change an industry?
The level of innovation is one of the things that’s super exciting about joining our team. There are some big opportunities around API stuff that we can get into if anyone wants to talk about it. It’s a great group of people, and we’re looking to do great things.
Check out current career opportunities with NuBrakes' engineering and product team, and help build the future of car care.