151: Groom Customer Champions with Rob Hirschfeld

14
Jun

Rob Hirschfeld is the Founder and CEO of The RackN Digital Rebar platform that helps organizations scale their automation efforts. We discuss ways to turn customers into raving fans, the fastest way to build trust in your business, and the pros and cons of open-source software. 

—

Listen to the podcast here

 

Groom Customer Champions with Rob Hirschfeld

Our guest on the show is Rob Hirschfeld, who is the founder and CEO of RackN, a digital rebar platform that helps organizations scale their automation efforts. Rob, welcome to the show. 

Thank you. I’m excited to be here.

Well, I’m very curious about you and your business here. So we’re going to dive right in. So tell me a little bit about your journey. How did you end up founding a company that does Digital rebar of all things?

Oh, my entrepreneurial journey for RackN started over 20 years ago when I was doing standard IT work and I was consulting. And at the time, I just kept having the same issue over and over again, which is an operations issue. I could write software. It took me as much time to deploy, install, get everything working as it took to write the software. And I found that incredibly frustrating. And that led me to starting my first startup, which was a cloud, one of the very first cloud companies.

My co-founder and I actually patented cloud back in 2001. So it’s a rare distinction. I’d never made any money on it. We were way too early. It’s always a challenge of being an entrepreneur. And, you know, a lot of ways what RackN does with Digital Rebar is exactly the same part of that journey. It’s asking that same question of “Why is it so hard for us to do the backend stuff, the, you know, running the infrastructure, making things work, you know, having that automation not take as much time as it takes.” It’s been a frustration of mine going all the way back. And, you know, RackN is my latest foray into trying to solve that problem as a product.

Well, you know, as I was getting ready for this interview, I was looking into your product and into your website, it says digital rebar. Let me Google that to see what this is exactly. And all the, you know, all the information I kept coming in was all about reinforced concrete and metal rods that are used in reinforced concrete. And the only info source that came up was your website about it. So I guess you coined that thing as well, right?

It’s definitely nice to have a product name that is unique in the industry. So Rebar, so for people who don’t know, Rebar is the steel that people put into concrete to make it more durable and ductile. It’s a core. It’s actually the absolute core requirement for buildings, skyscrapers and buildings and bridges. And, you know, digital rebar for us as a name accomplish two things. One is, it is actually a good description of what RackN provides, which is the foundational pieces for building infrastructure and all the things that you build cloud applications, IT businesses around, which is really our focus.

But it’s also an homage back to the original name of the product, which was Crowbar. And so when we started this journey, we started with an open source project that we named Crowbar, being the first tool that you use in— there’s a Half-Life video game— and the first you start with a crowbar and no other tool. And so the idea was that you would use a crowbar to get your infrastructure built. And when that name— when it was time to sunset that name, the team wanted something that people in the know, wink and nod, would understand that was a reference back. And so Rebar accomplished both purposes. It turned out to be quite a good name for us.

Okay, well, definitely interesting and we’re gonna get into this a little bit more. I have more questions, but before we go there, let’s talk about the framework that you’re bringing on this show. And I think we call it the build an internal champion framework or build internal champions framework. So can you explain to the listeners what this is about and why it’s important and how you go about doing it? 

I’d be happy to. So, we reckon is a product led company, and this is something that we had to figure out through trial and error. So some people would expect we’d call up CIOs and executives and get them to take our product and then bring that forward in the organization. We actually tried that. We had a salesperson and did that work. It didn’t really work for us. What we found was that the people actually running the infrastructure, doing the implementations, could very easily throw sand in the gears and make everything not work. And so for us, no matter how much executive sponsorship we had, we actually had to win over the hearts and minds of the people who were going to run the system. And that is actually where we really shifted our strategy into a product led strategy.

So everything we do with RackN is get people to install, use, validate, make sure it works right. It’s a very hands on experience. has led us to the point where once that person has tried the product, has used the product, has validated it at work, sometimes without talking to us at all, they understand the vision of what we’re doing with the product and how it helps them, and they become an internal champion. And so our sales motion is really reliant on the idea of this architect leader who’s done an evaluation, been hands-on, sees how we can solve a problem, and then they carry the value internally, what we call an internal champion, forward in their organizations. And in a lot of cases, it’s really helpful to us because most enterprise IT organizations don’t want a vendor, you know, sort of coming in and back-channeling, playing golf with the executives and influencing people, they really count on their internal references to make that work.

And so us building confidence in those internal champions is a really, really important way for us to sell product. Sometimes it’s a little bit invisible because they’re doing a whole bunch of that legwork without us knowing. And so there’s always pros and cons to any sales strategy. But for us, having those internal champions has been absolutely essential. We’re getting along old enough now that we have internal champions who’ve changed jobs and become internal champions in their new organizations. That is often just a fantastic way to walk into a new account.

That’s great. Do you even have a SaaS function in the business or do you call it something else? 

SaaS is one of those words that have multiple meanings. 

Sorry, I didn’t say SaaS. Sales, sales function. Is there a sales function in the business or you just-

Oh, that’s a great question.

You just catalyze these champions and they take care of it and it’s a very long-term approach.

We really don’t. I mean, we have sales work, but it’s really handled by our sales engineering team much more than our sales process, right? As CEO, I do a lot of the what people would traditionally call sales work. And we have classic things like a pipeline and a deals chart and things like that. But from a classic call people up and, you know, try and get them to buy the product, we really don’t at the moment have that. We’re talking about adding it more, but our first focus is really on helping people find our product, download the product, install, use it, and get that conversion experience. And that is such a cost-effective way to sell that we have a lot more juice in the lemon, if you will, to squeeze out to help make that process easier and more effective. And it’s beautiful because once those architects understand the product, if we can empower them to sell in their organizations, then they really do a lot of that work for us.

So how do you generate that initial interest? How do you even conjure up their interest? How do they find you?

That is always a challenge. That’s the marketing piece. It comes back down to storytelling. So there’s a degree of awareness. There’s a degree of having people be able to look at our website and understand what we do, which is something that is actually one of the hardest. That is the hardest thing we have to do in the business is actually to have simple explanations that people link back into their problems. And that’s, we spend a lot of money doing advertising and LinkedIn, sponsoring conferences, talking at conferences, explaining the challenge. And you have to do it in a way that isn’t very vendored. It’s the way I would describe it. So most of those outlets aren’t looking for a, you know, “Come try RackN, we’re great.” You have to frame it in their problem space.

And, you know, “You’re looking to solve this problem.” Here’s how we help you solve that problem, or here’s how you can think about that problem and check out RackN, we solve it really well. So it’s a really careful narrative. It’s very storytelling focused. And one of the things that for us has been a challenge is helping or having our customers tell that story for us more. So a referral type or a public story would really go a long way in cases like that. Our customers typically are very sensitive about using their name, their banks, media companies, hosting companies. And so that for us has been one of those slower processes that really help people understand how the product is used. So it’s the other side of having operators start the process is that they typically hold things very close to their chest. They don’t want everybody else to see their cards. And so that is probably one of our biggest challenges in storytelling.

Ok, so basically your sales processes or marketing slash sales process is to get the word out on this problem and how it can be solved and then get it in front of the potential champions who are the programmers, the engineers working these tech companies?

It does. That’s exactly right. One of the things that we do in that that’s really helpful for people to understand is we look for larger trends that we can be part of. So there have been times when we’ve tried to coin terms or lead in conceptual thinking, it is incredibly hard to do that. That’s an evangelism sale. Instead, what we do, and right now we’re in the middle of this exact thing, we look for industry trends where there’s a good match. Right now, in the tech circles, platform engineering is a phrase that people really understand and they’re starting to discuss a lot.

And so what we typically do is instead of trying to create a unique message, what we’ll do is we’ll describe how we support platform engineering efforts and how we make that a better story, which might be counterintuitive to some people. We’re not running around. We’re still telling people how we’re unique and differentiated and helpful, but we’re doing it as part of a story that they already understand instead of trying to explain, tell them the alternatives, you have to say, you’re doing something wrong, and we will help you fix that. That can be a harder message to convey. Sometimes if it’s very painful, then it’s an easy thing, but for a lot of IT stuff, there’s way too many alternatives to just sell, I have a better widget.

Yes. It’s basically a PR strategy. I don’t know if you do it with the news media or is it blogs, but essentially you are tapping into trends and sharing your take on it and attract attention.

That’s exactly it. It’s literally that simple. It’s not simple, but that’s how it ends up working. And those customer stories end up being key. From a media perspective, they don’t want to talk about vendors. They want to talk about customer success.

Yeah, of course. So switching gears here a little bit, one of the things that you told me about is this idea of open source and closed source and how your business evolved from the open source towards closed source, perhaps, or some kind of a hybrid. What is your thinking about that? What are the pros and cons of open source? And what is your view of the future of RackN?

This is a really important topic, and it’s one that I’ve come to appreciate has a lot of different sides and facets to it. And even if you’re not an open source technologist, most businesses today are impacted by open source. And so if you’re a leader and don’t understand this phenomenon, it actually can catch you on the blind side in a really challenging way. Because of the history of how RackN started, going back to that first open source project, Crowbar, we really had this idea that open source was important in our life cycle. So we do, in the data center space where we are, there’s a lot of open source technologies that people use and rely on. There’s a lot of closed source technologies and closed technologies also, servers aren’t free and open, you have to buy them.

A lot of software that our customers use, they have to buy. But there’s definitely a trend towards the adopter, and this is the distinction, that the people often making the evaluation for our technology don’t want to pay any money for it or want to be a technologist that they can help contribute and build to it. And so our original life as a product company was all open. So the core of our technology was open. We were attracting very big name companies and they would come in, they would see the core technology, they’d get very excited about it and they would start implementing it in their data center. And because it was open, they had no obligation back to RackN to contribute, pay, participate, amplify.

When you’re in an open source community, there’s a lot of ways that you can pay back to the people supporting the software. People assume that that means contribute back, but, you know, like actually write the code with them. That actually doesn’t happen very often. It’s much more common that you say that you’re using the software, you pay for support. Or a lot of times people, and this is what we’ve been doing, they create a model where most of the software or core parts of the software are open, but then there’s a whole bunch of pieces that are necessary to make it enterprise grade that are closed. And so what a company, what we used to try to do was open the core software and then have people pay for the enterprise enhancements.

The challenge for our process was that our customers, that we wanted to be customers, our users, would take that software and then replicate the pieces that we were trying to have them pay for because they didn’t want to pay us money. And that was not a very sustainable model for us, right? We kept getting requests to improve that core from companies that were determined to bypass our payment mechanism for this. And it just ends up being a very frustrating challenge when you’re dealing with companies that are top known brands in the world. And this is true of how they operate in the space. They will use open source technologies. And the benefit that the company like us would get is that they’re being used by those companies. I think that isn’t much of a benefit if they’re not paying you. Yeah. 

And I think there is even some kind of an expression. I paraphrase it, but it’s something like “Improve and destroy” or improve and annihilate or something like that. So you take an open source, you improve on it, and essentially then you will make it incompatible to all those other people who have open source. They can only use the improved version if they buy your service or subscribe to you. And essentially, because your product is better than the open source product, you attract all the customers and the open source product dries, dies.

That does happen. There’s a lot of ways that those projects can generate bad will from that perspective. We actually made a very different decision. We reached a point where our paying customers needed significant improvements and enhancements in that core platform. And we made a decision that, you know, those enhancements were basically a rewrite of that core or significant changes to the core. And we chose to close the core from that perspective. Not for, we closed the core because that was where we kept adding this value. There was actually an interesting piece to this that lines up with RackN’s mission here because our mission in building the company was to eliminate what I call toil in the automation and operations space.

So in IT operations, one of the problems people have is that every company seems to repeat the same work a little bit differently, but they keep repeating the same work. And it makes it very expensive and hard for anybody to help them, for them to help each other, for them, for people they hire to understand what’s going on. They have to relearn everything. And it’s the whole system is very fragile. Data centers keep working happily, but most data centers require a lot more maintenance than they should. It would be like back in the turn of the century when people were building boilers custom. I love this analogy.

And so you walk into a building and they have a custom boiler. They had to have somebody who maintained it, and then things would catch on fire or explode. There were a lot of boiler accidents because people built boilers, however, you know, just out of pipes and elements. And then we started to standardize those operations so that everything was the same and there were patterns and safety standards and things like that, building codes. And what we wanted were more direct and…

That means that part of the boiler could be replaced by a standard part and you didn’t have to rebuild the whole boiler, right?

Correct. And the waste pipes fit together with standardized, what went in the walls was standard. What we started to do is have repeatable standards for how things work. So you could hire somebody and they would already know what to do. Or if a manufacturer found a defect, they could fix it for you, right? You didn’t have to have somebody come in and try to figure out if there was a problem or not. And that’s really what RackN does for automation. So we don’t just build this platform, but all of the automation software that goes into running a data center, we standardize and we allow our customers to reuse standard libraries that do that work.

And it’s transformative for our customers because now they’ve gotten out of having to build custom data center automation and they can use standard data center automation. But that wasn’t working when our customers would bypass that part of the automation. So they would say, oh, you know what? I don’t want to pay for this. I’m going to write my own custom in this place where Racken is trying to create standards. By flipping the model, we actually fit our mission much better. So now we can open source all of these standard automation, let people see it and reuse it, we’re not worried if they copy the open pieces that we want them to copy the open pieces. And we’re not worried about them basically sacrificing our business model by using and reusing this part of the software.

So the flip for us was much more on mission for what we wanted to accomplish. It’s also much more straightforward. I’m a big fan of simple pricing when I can do it. And when somebody can call you up and say, “I want to use your software, how much does it cost?” And you’re “Like this and we’ll support you. And if it goes down, we’ll help you.” All very simple. When you’re dealing with open source, people use your software and it’s not clear when they start using it, how they’re going to pay you and compensate you and what the interaction is going to be if they find a bug or an issue. A lot of times that’s when the cash register goes. So you’ve got this situation where somebody’s like, “Ah, I need help.” And you’re like, “Well, now you have to pay me.” And our customers getting paid by enterprises is not always a fast process. And so it really puts a lot of friction into the relationship that just selling software, you have to get over the selling part, but the friction once you’ve created that relationship is zero.

Yes. You get what you paid for basically. And if it’s transparent, you know, ahead of time, what you’re going to pay, it’s much better than if you just get a surprise bill and then now you have to figure out how to take care of it.

I really like and our customers like, you know, a very direct, you know, “I need this service. It solves this problem for me. I will pay to have that service solved and not a surprise. Oh, I didn’t realize we were using this core technology and it doesn’t have support or a lifecycle or there’s a security flaw in it and I don’t know who to call up to get it fixed.” This is where no matter what line of business you’re in, you are using open-source technology and if you don’t understand that commercial relationship you have with that technology and who’s going to answer those questions for you, it’s a very serious problem. For RackN, flipping our model made that answer much simpler.

So what I’m curious about is what makes an automation platform be scalable? And does that platform have to be a SaaS company to scale? Or there are other ways? And what network effects exist for you to scale the company, if any? 

Wow. There’s a lot of pieces for that. Scale is probably the hardest thing to do of any system. And I’ll tackle that first, because in some ways, it’s very simple. Rehearsal is actually the key success to scalability. There’s two of them. One is reliability, and the other one is rehearsal. And if reliability is actually tied up in rehearsal and exercise, and if you’re not a fan of exercise, sorry, this is actually the true benefit here. If you want any process to scale, this is true of tech, I actually think this is true of business also and what I see in business, is the more you exercise a process, the more confident you are that you can run that process and validate it, doing it more often, that actually creates scalable processes every single time.

Things that aren’t done very often, very fragile, hard to scale. Things that are done very often but fail a lot, right? You’re gonna fix that because you’re doing it all the time. Improves reliability, reliability and repetition translate into scale. Very straightforward answer from that perspective. Hard to accomplish. And there’s a ton of architecture pieces and things I could go into in the tech architectures, I give talks about that. But I think from a pragmatic, what does it take for my organization to scale? If you built on top of anything in your business that you’re not confident that you can run it over and over and again and repeat the process and exercise it, then it’s not gonna scale. And that’s how I look at everything we do, from our sales processes to our marketing, you know, to our engineering and how the product works. And we really, really work with our customers to have exercise built into their processes.

The thing that makes RackN unique is we’ll actually help people build automation that has a dev cycle and a test cycle and a distribute-to-production cycle, which is normal for software development, very unusual for automation. But that, and this is where the SaaS or not SaaS comes in for us, that process allows our customers to take our product, the automation, and test it in their own environments, and then roll it out. RackN is a software company, which means we sell software, it’s versioned, our customers download that software and they run it. We’re not a SaaS in that we don’t run the software for our customers. And typically, a scalable SaaS, we would have one version of the software, something running in the cloud, and all of our customers would use that same version. For what we do, that is not a workable model because the automation actually changes things in their operating environments.

And it would be very problematic if RackN made a change to automation and decided for our efficiency that we were going to roll out that change to all of our customers. The likelihood of that breaking a customer is pretty high. And that would take down their infrastructure, break their servers, fail their applications. It might cause all sorts of havoc. So if we were doing that work as a SaaS and then rolling out those changes without our customers’ control, we would actually be breaking our customers on a daily basis. On the other side of it, it’s really important.

And so we, as a software company, we will write and test our software, but then our customers get the choice of when they make that transition. So they maintain the control of when the automation changes, how it’s deployed, how it’s tested, right? They validate it against their environment. My company would have to be much, much bigger. I don’t even think there’d be possible for us to have enough confidence to roll out changes if we were doing it for our customers’ behalf. But the way we do it actually does exactly now we’re going all the way back to the champions. The champions want control. That’s what we sell. And we are very careful never to take that control away from them. We partner with them to improve their control. If we were a SaaS and I was throwing a switch and changing things for them, that would be very…

Disaster.

It would be a disaster.

Yeah. That’s very interesting. Very interesting. I love what you said about the rehearsal and reliability and the repetition. So, you know, I always think about Bruce Henderson from BCG, Boston Consulting. He talked about the experience curve. Every time you double the number of repetitions, your productivity improves by 20 to 30 percent. And I tell my clients that if you constantly are chasing shiny objects, essentially you deny yourself the productivity improvements that your competitors are going to get who are sticking with this process and the scissors that I open up and three years from now, you’re going to be a mediocre company and they’re going to be a hugely profitable company.

That’s a very real thing. The interesting thing, thinking about that from the way automation is written today, everybody writes their own automation. Even if you’re best in class and you do all the work and all the exercising in your own silo, in your own company, you’re still going to get out-competed by what we’re doing with our customers because we’re actually getting the benefit of that exercise across our customer base. And that’s one of the things that gets me really excited about RackN from the way you’re describing it. It’s like, all right, automation is not usually a value-added activity for any business. They’re just running the infrastructure. It’s what they do above it that adds value. But if they get the benefit of exercising the automation across all of our customers, and they only have to do 1% of that exercise versus 99 for the whole 100, then all of a sudden they get the acceleration that comes from that type of work. Even if they don’t realize they’re doing it, they’re getting that benefit. It’s incredibly powerful and aggregate. Harder for an individual customer to understand until they start seeing how they can take advantage of standard practices. Right now, we’re back to the boilers.

Yes. So if you want to replace your boilers with scalable ones, then I encourage you to reach out to Rob at RackN. They will make sure that all your automations are standardized, best practice, and so you can get the repetitions in and you get the productivity improvement in over time. So if people would like to experiment, if they want to be a champion and want to try your product, or they want to learn more and reach out to you, where should they go? 

Very simple. I am robrackn.com. Online, you can find me in a lot of different places as Zehicle, Z-E-H-I-C-L-E. It’s a handle that goes back to my electric car days when I was building electric cars. It’s a whole other story. Okay. But, yeah, RackN.com, you know, if you want to try it, we really do encourage that champion approach and download, try, and use the product. The product is really the thing that speaks for us more loudly than any of the marketing material I can put together

Awesome. Well, thank you, Rob, for sharing this and talking about automation and scaling. That’s always exciting on the show. Thank you. 

Thank you, Steve. I appreciate the time. This was a really fantastic conversation. We covered a lot of critical points in tech and in business. So thank you. 

 

Important Links:

This entry was posted in . Bookmark the permalink.